A vulnerability was found in Feehi CMS up to 2

CVE-2026-13546 is a CWE-287 *improper authentication* flaw in Feehi CMS through version 2.1.1 — a small Yii2-based content management project (liufee/cms on GitHub) that's primarily used as a learning/demo CMS in Chinese developer circles. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L indicates network-reachable, unauthenticated, low-complexity exploitation that yields *partial* confidentiality, integrity, and availability impact — consistent with bypassing a login check on a specific endpoint or weak session handling rather than full admin takeover. No vendor advisory, no PoC repo, no exploit-db entry, no GitHub Security Advisory text beyond the bare CVE assignment as of disclosure day.

The vendor/CNA score of 7.3 HIGH is defensible on paper because three Low impacts add up arithmetically, but it ignores the practitioner reality: Feehi CMS has a Shodan/Censys footprint in the low hundreds globally, no enterprise penetration, no commercial deployments worth naming, and a maintainer who hasn't shipped a release in years. The triple-Low impact metric — meaning the bypass does not yield full admin or RCE on its own — confirms this is not a domain-takeover bug. For an enterprise defender running 10,000 hosts, the realistic exposure is effectively zero unless a developer stood up a sample app and left it on the internet.

Why this verdict

• Vendor score inflation: CVSS 7.3 is arithmetically correct but the triple-Low impact metric means this is *not* a full takeover — it is a partial bypass yielding limited read/write on a single resource scope.
• Population friction: Feehi CMS public exposure is in the low hundreds globally per Shodan/Censys — orders of magnitude smaller than any product that warrants a HIGH operational verdict.
• Role multiplier: Feehi is never deployed as an identity provider, hypervisor, backup server, CA, kernel agent, or any other high-value-role component in the noisgate catalog. Worst plausible role is a marketing microsite or a developer's lab box — blast radius caps at *one host, one tenant*. The deployment-role floor does not apply.
• No KEV / no PoC / no campaign: disclosed today by a research CNA with no exploitation evidence and no expected attacker investment given the tiny target population.
• No vendor fix expected: upstream liufee/cms is effectively abandoned, which makes *removal* the only viable long-term control — that's a config/lifecycle issue, not a patching emergency.

Why not higher?

HIGH would be appropriate if Feehi were enterprise software, or if the impact metrics were High across CIA, or if there were active exploitation in the wild. None of those hold. The CVSS arithmetic produces 7.3 but the operational picture is a niche CMS with partial-impact bypass.

Why not lower?

LOW or IGNORE would be wrong because the flaw *is* remotely reachable with no authentication and no user interaction, and a defender who has a Feehi instance on the perimeter (rare but real) still has a real bug to fix. MEDIUM acknowledges the real, exploitable bug while reflecting the negligible blast radius.

1. Inventory for any Feehi CMS instance on the network — Run an external ASM sweep (Censys, Runzero) and an internal HTTP fingerprint pass for the Feehi favicon hash and /admin login banner. Per the noisgate MEDIUM SLA there is no mitigation deadline — handle in normal asset-inventory cadence, ideally within the next monthly review.
2. Block the affected endpoint at the WAF or reverse proxy — Once a PoC names the vulnerable route, add a WAF deny rule for that path. Until then, restrict /admin and any non-public Feehi paths to an IP allowlist. Deploy alongside your normal MEDIUM remediation work — no fast-track required.
3. Remove or replace Feehi CMS entirely — Upstream is unmaintained; this CVE will not be patched. Migrate the content to a supported CMS (WordPress, Ghost, Strapi) within the 365-day remediation window. This is the only durable fix.
4. Put any Feehi instance behind authenticated reverse proxy (SSO/MFA) — Cloudflare Access, AWS ALB-OIDC, or an internal SAML proxy in front of Feehi neutralizes the PR:N/UI:N attack vector without touching application code. Implement in the normal change window.

Run this from an auditor workstation or an internal scanning host with network reach to your candidate targets. Invoke as ./check-feehi.sh https://target.example.com — no privileges required, just outbound HTTP. The script fingerprints Feehi CMS and reports the version exposed.

#!/usr/bin/env bash
# noisgate verifier: CVE-2026-13546 (Feehi CMS <= 2.1.1 improper authentication)
# Usage: ./check-feehi.sh <base-url>
# Exit codes: 0=PATCHED/NOT_FEEHI, 1=VULNERABLE, 2=UNKNOWN
set -u
TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "usage: $0 <base-url>" >&2
  exit 2
fi

UA='noisgate-verifier/1.0'
# Pull root and login page; Feehi advertises itself in HTML meta + Yii2 cookies
ROOT=$(curl -ksS -A "$UA" --max-time 10 "$TARGET/" || true)
ADMIN=$(curl -ksS -A "$UA" --max-time 10 "$TARGET/admin" || true)

if ! grep -qiE 'feehi|liufee' <<<"$ROOT$ADMIN"; then
  echo "PATCHED (no Feehi CMS fingerprint on $TARGET)"
  exit 0
fi

# Extract version from generator meta or footer credit
VER=$(grep -oiE 'feehi[^<"]{0,40}' <<<"$ROOT$ADMIN" | grep -oE '[0-9]+\.[0-9]+(\.[0-9]+)?' | head -1)

if [[ -z "$VER" ]]; then
  echo "UNKNOWN (Feehi detected on $TARGET but version not parsed — treat as VULNERABLE until proven otherwise)"
  exit 2
fi

# All currently published Feehi releases (<=2.1.1) are affected; no fix released
awk -v v="$VER" 'BEGIN{
  split(v,a,"."); maj=a[1]+0; min=a[2]+0; pat=a[3]+0;
  if (maj<2 || (maj==2 && min<1) || (maj==2 && min==1 && pat<=1)) { print "VULNERABLE (Feehi " v " on target — CVE-2026-13546 applies, no upstream fix)"; exit 1 }
  else { print "UNKNOWN (Feehi " v " — newer than 2.1.1, verify against vendor advisory)"; exit 2 }
}'

Sources

1. VulDB / CVE.report — Feehi CMS history
2. CVE Details — Feehi CMS 2.1.1
3. Feehi CMS upstream repository (liufee/cms)
4. Exploit-DB 51018 — Feehi CMS 2.1.1 Authenticated RCE
5. Exploit-DB 51002 — Feehi CMS 2.1.1 Stored XSS
6. GHSA — Feehi CMS host header injection (CVE-2022-38796)
7. CWE-287: Improper Authentication
8. CISA KEV catalog (Feehi not listed)