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.
3 steps from start to impact.
Identify a Feehi CMS instance
/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.- Target must be running Feehi CMS 2.1.0–2.1.1
- Instance must be internet-reachable
- 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
Send unauthenticated GET/POST to /api/articles
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.- The
/api/articlesroute is reachable (not blocked by WAF, reverse proxy, or IP allowlist)
- 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
/api/* paths. Standard access logs will show API calls without session cookies.Read or modify article content
- Successful step 2
- 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
/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.- 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
HttpBearerAuthor 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.
The supporting signals.
| In-the-Wild Exploitation | None 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-Concept | Public. 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. |
| EPSS | 0.00654 (0.654%), approximately 49th percentile. Indicates very low predicted exploitation probability — consistent with the negligible installed base. |
| KEV Status | Not listed. No CISA KEV entry as of 2026-10-02. |
| CVSS Vector | CVSS: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 Versions | Feehi CMS 2.1.0, 2.1.0.1, 2.1.0.2, 2.1.1. Last release was August 2020. Project appears abandoned. |
| Fixed Version | None. 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 Details | Disclosed 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 CVEs | Feehi 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.
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.'
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.
#!/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