← Back to Feed CACHED · 2026-10-01 19:05:52 · CACHE_KEY CVE-2026-13546
CVE-2026-13546 · CWE-287 · Disclosed 2026-06-29

Feehi CMS REST API /api/articles Missing Authentication

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like someone left the gate open at a ghost town's community bulletin board

CVE-2026-13546 is a missing-authentication flaw in Feehi CMS's /api/articles REST endpoint. Versions 2.1.0 through 2.1.1 ship the endpoint without any authentication check, letting any unauthenticated remote caller read, create, or modify article (blog post) records. The vulnerability is trivial to exploit — it's a simple HTTP request to a public URL — but the blast radius is confined to CMS article content: titles, body text, metadata, and possibly unpublished drafts. There is no demonstrated path to remote code execution, credential theft, or lateral movement from this bug alone. The affected component runs on Yii2/PHP and the vulnerable endpoint follows Yii2's default RESTful resource routing.

The vendor's CVSS 3.1 score of 7.3 HIGH significantly overstates the real-world risk. The CVSS v4.0 re-score already corrected this to 5.5 MEDIUM. But even that is generous given the context: Feehi CMS has approximately 2,960 total Packagist installs over its entire lifetime, its last release (2.1.1) shipped in August 2020, the maintainer has not responded to this or other security reports, and the project has zero downstream dependents. For any enterprise running 10,000 hosts, the probability of encountering Feehi CMS in your fleet rounds to zero. The impact — unauthenticated article CRUD — is website-defacement-grade, not data-breach-grade. The vendor HIGH label reflects a mechanical CVSS calculation (unauthenticated + network-accessible) without considering what is actually at stake.

"Abandoned PHP CMS with ~3K total installs; article-only exposure is not enterprise-grade risk."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Identify a Feehi CMS instance

The attacker locates a Feehi CMS deployment by fingerprinting HTTP response headers, the default /index.php routing pattern, or Yii2/Feehi-specific HTML signatures. Shodan/FOFA/Censys scans for X-Powered-By: Feehi or the default theme's CSS/JS paths would surface targets. Given ~3K total installs worldwide, viable targets are extremely scarce.
Conditions required:
  • Target must be running Feehi CMS 2.1.0–2.1.1
  • Instance must be internet-reachable
Where this breaks in practice:
  • Feehi CMS has ~2,960 total Packagist downloads lifetime — finding a live instance is the hardest part of this chain
  • The project is abandoned (last release: Aug 2020); most installs are likely defunct dev/test instances
Detection/coverage: Standard web application scanners (Nuclei, Nikto) can fingerprint Feehi CMS. No dedicated Nuclei template for this CVE was found on pocindex.io.
STEP 02

Send unauthenticated GET/POST to /api/articles

The attacker sends a direct HTTP request — GET /api/articles to list articles or POST /api/articles with JSON body to create/modify content. No credentials, tokens, cookies, or headers are required. The Yii2 REST controller processes the request as if it were from an authenticated admin because no beforeAction auth check exists on the API controller.
Conditions required:
  • The /api/articles route is reachable (not blocked by WAF, reverse proxy, or IP allowlist)
Where this breaks in practice:
  • Many small CMS deployments sit behind Cloudflare or similar CDN/WAF that may restrict non-browser API calls by default
  • If the instance uses path-based routing rewrites that strip /api/, the endpoint may not be reachable
Detection/coverage: WAF rules matching unauthenticated POST/PUT/DELETE to /api/* paths. Standard access logs will show API calls without session cookies.
STEP 03

Read or modify article content

The attacker can now enumerate all articles (including unpublished drafts), modify existing article body/title/metadata, or create new articles. This is the terminal impact — website defacement or information disclosure of draft CMS content. There is no documented escalation from article CRUD to shell access, database credential exposure, or admin panel takeover through this endpoint alone.
Conditions required:
  • Successful step 2
Where this breaks in practice:
  • Impact is limited to CMS article content — no demonstrated RCE, no credential leak, no pivot to backend systems
  • Modifying articles on an abandoned ~3K-install CMS has negligible real-world consequences
Detection/coverage: Content integrity monitoring (file-hash or database-hash checks) would detect unauthorized article changes. CMS audit logs (if enabled) would record the modifications.
03 · Compensating Control

1
LOW 3.0→IGNORE 0.0
SEVERITY REDUCED
Block /api/* paths at the reverse proxy or WAF — Add a deny rule for all requests matching /api/* at your reverse proxy (nginx, Apache, Cloudflare, AWS ALB) or WAF. This kills the entire attack surface for this CVE and related API-based Feehi vulns in one rule. Since Feehi CMS is a LOW-severity finding, there is no noisgate mitigation SLA — go straight to the remediation window. However, if you confirm a live instance, apply this block immediately as the vendor will never patch.
2
LOW 3.0→IGNORE 0.0
SEVERITY REDUCED
Decommission Feehi CMS entirely — Given 28 CVEs including RCE and hardcoded crypto keys, plus vendor abandonment since 2020, the correct remediation is full decommission. Migrate content to a supported CMS (WordPress, Ghost, Hugo). Per the noisgate remediation SLA for LOW, you have backlog-priority latitude, but the systemic security debt makes decommission the only responsible path.
3
LOW 3.0→IGNORE 0.0
SEVERITY REDUCED
Restrict network access to the CMS instance via firewall rules — If immediate decommission isn't feasible, place the Feehi CMS host behind an IP allowlist at the network layer so only authorized internal users or a CDN edge can reach it. This prevents unauthenticated internet-origin exploitation of all Feehi endpoints.
What doesn't work
  • Upgrading Feehi CMS — there is no patched version. The vendor has not released a fix and the project appears abandoned since 2020.
  • Adding authentication via Yii2 config — while theoretically possible by editing the Yii2 controller config to require HttpBearerAuth or similar, modifying an unsupported codebase introduces maintenance risk and does not address the 27 other CVEs in this product.
  • Rate limiting — throttling API calls does not prevent exploitation; a single request is sufficient to read or modify articles.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone observed. Not listed in CISA KEV. No reports from GreyNoise, Shadowserver, or threat intel feeds. The negligible installed base makes mass exploitation economically pointless.
Proof-of-ConceptPublic. The vulnerability was disclosed via GitHub issue #87 on the liufee/cms repo. The PoC is trivial — a single unauthenticated HTTP request. No dedicated exploit repo found on GitHub or pocindex.io. No Nuclei template, no Metasploit module, no ExploitDB entry for this specific CVE.
EPSS0.00654 (0.654%), approximately 49th percentile. Indicates very low predicted exploitation probability — consistent with the negligible installed base.
KEV StatusNot listed. No CISA KEV entry as of 2026-10-02.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L — Unauthenticated network attack, low complexity, but all three impact dimensions are Low. CVSS v4.0 rescored to 5.5 MEDIUM (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P), which better reflects the limited impact.
Affected VersionsFeehi CMS 2.1.0, 2.1.0.1, 2.1.0.2, 2.1.1. Last release was August 2020. Project appears abandoned.
Fixed VersionNone. Vendor has not responded to the security report. No patch, no workaround from upstream.
Installed Base~2,960 total Packagist downloads (lifetime). 533 GitHub stars, 180 forks, zero dependents. Does not register on any CMS market share report. For context, WordPress has 43.6% market share; Feehi CMS is statistically invisible.
Disclosure DetailsDisclosed 2026-06-29 via GitHub issue. VulDB tracking ID VDB-374554. Researcher not publicly attributed. The vendor (liufee) was notified but has not responded.
Related CVEsFeehi CMS has 28 CVEs total including CVE-2026-86241 (hardcoded crypto key), CVE-2026-86240 (SSRF), and issue #78 (RCE via unrestricted file upload). The product has systemic security debt — this is one of many issues in an unmaintained codebase.

Sources.

  1. NVD — CVE-2026-13546
  2. OSV — CVE-2026-13546
  3. GitHub Issue #87 — liufee/cms
  4. OpenCVE — CVE-2026-13546
  5. Hol Security — CVE-2026-13546 Advisory
  6. Packagist — feehi/cms Download Statistics
  7. CyberStrike — CVE-2026-13546 Detail
05 · The Call

Final Verdict
↓ DOWNGRADED to LOW (3.0/10)

Why this verdict

  • Negligible installed base eliminates fleet-scale risk. Feehi CMS has ~2,960 total Packagist downloads over its lifetime with zero dependents. In any enterprise fleet of 10,000 hosts, the expected count of Feehi CMS instances is effectively zero. The vendor HIGH score assumes the product matters — it doesn't at enterprise scale.
  • Impact ceiling is website defacement, not data breach or RCE. The unauthenticated endpoint exposes article CRUD operations only. All three CVSS impact dimensions are Low. There is no demonstrated escalation to shell access, credential theft, or lateral movement. The worst outcome is someone editing your blog posts on an abandoned PHP app.
  • Role multiplier: not a high-value-role component. Feehi CMS is a small open-source content management system for websites/blogs. It is not an identity provider, hypervisor, CI/CD system, database engine, backup solution, network appliance, or any other high-value-role component. Its deployment role is exclusively low-value (personal blogs, small websites, dev sandboxes). The blast radius of full compromise is a single website's article content — no domain takeover, no fleet compromise, no supply-chain impact. The high-value-role floor does NOT apply.
  • Abandoned project with no patch path. The last release was August 2020. The vendor has not responded to this or other security reports. The 28 total CVEs (including RCE and hardcoded keys) suggest anyone still running Feehi CMS should migrate off it entirely, not patch individual CVEs.
  • No exploitation activity whatsoever. No KEV listing, no GreyNoise/Shadowserver hits, EPSS at 49th percentile. The economics of exploiting a ~3K-install CMS to deface blog posts do not justify attacker investment.

Why not higher?

The unauthenticated network-accessible vector (AV:N/PR:N) mechanically produces a CVSS 7.3, and there is a public PoC. However, severity should reflect *actual risk to the defender's fleet*, not theoretical worst-case for a product nobody runs. The impact is confined to article content (C:L/I:L/A:L), the installed base is negligible, there is no demonstrated escalation path, and no attacker is targeting this software. Upgrading to MEDIUM would overstate the urgency for any enterprise patch queue.

Why not lower?

Despite the negligible installed base, the vulnerability is real, unauthenticated, and trivially exploitable. If an enterprise somehow does run Feehi CMS (perhaps a forgotten dev instance), the exposed endpoint requires zero skill to abuse. Marking IGNORE would risk dismissing a legitimate finding during asset inventory. LOW correctly signals 'fix if present, but don't hunt for it.'

06 · Verification

Crowdsourced verification payload.

Run this on any machine with curl and network access to the target Feehi CMS instance. Invoke as: bash check_cve_2026_13546.sh https://target.example.com. No special privileges required — it makes a single unauthenticated HTTP GET request.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-13546 Checker — Feehi CMS /api/articles Missing Authentication
# Usage: bash check_cve_2026_13546.sh <base_url>
# Example: bash check_cve_2026_13546.sh https://cms.example.com
# Exit codes: 0 = VULNERABLE, 1 = PATCHED, 2 = UNKNOWN

set -euo pipefail

if [ $# -lt 1 ]; then
  echo "Usage: $0 <base_url>"
  echo "Example: $0 https://cms.example.com"
  exit 2
fi

BASE_URL="${1%/}"
ENDPOINT="${BASE_URL}/api/articles"

echo "[*] CVE-2026-13546 — Feehi CMS Missing Auth Check"
echo "[*] Target: ${ENDPOINT}"
echo ""

# Send unauthenticated GET to /api/articles
HTTP_CODE=$(curl -s -o /tmp/cve_2026_13546_response.json -w "%{http_code}" \
  -X GET "${ENDPOINT}" \
  -H "Accept: application/json" \
  --connect-timeout 10 \
  --max-time 15 2>/dev/null || echo "000")

if [ "${HTTP_CODE}" = "000" ]; then
  echo "[!] UNKNOWN — Could not connect to ${ENDPOINT}"
  rm -f /tmp/cve_2026_13546_response.json
  exit 2
fi

echo "[*] HTTP response code: ${HTTP_CODE}"

if [ "${HTTP_CODE}" = "200" ]; then
  # Check if response contains article data (JSON array or object with article fields)
  if grep -qiE '"id".*"title"|"content"|"created_at"' /tmp/cve_2026_13546_response.json 2>/dev/null; then
    echo "[!] VULNERABLE — /api/articles returned article data without authentication"
    echo "[*] Response preview (first 300 chars):"
    head -c 300 /tmp/cve_2026_13546_response.json
    echo ""
    rm -f /tmp/cve_2026_13546_response.json
    exit 0
  else
    echo "[?] UNKNOWN — Got HTTP 200 but response does not look like article data"
    rm -f /tmp/cve_2026_13546_response.json
    exit 2
  fi
elif [ "${HTTP_CODE}" = "401" ] || [ "${HTTP_CODE}" = "403" ]; then
  echo "[+] PATCHED — /api/articles requires authentication (HTTP ${HTTP_CODE})"
  rm -f /tmp/cve_2026_13546_response.json
  exit 1
elif [ "${HTTP_CODE}" = "404" ]; then
  echo "[+] PATCHED — /api/articles endpoint not found (HTTP 404); API may be disabled or not Feehi CMS"
  rm -f /tmp/cve_2026_13546_response.json
  exit 1
else
  echo "[?] UNKNOWN — Unexpected HTTP response code: ${HTTP_CODE}"
  rm -f /tmp/cve_2026_13546_response.json
  exit 2
fi