Summary
FeehiCMS, a Yii2-based CMS, exposes a UEditor file-upload endpoint without authentication. The CVE advisory lists the affected range as up to 2.1.1; runtime verification was performed only on 2.1.1. A wildcard route prefix in the backend access-control whitelist matches the upload action via prefix matching, and CSRF validation is disabled on that action. When the backend entry point is network-reachable and initialization is complete, an unauthenticated attacker can upload files with whitelisted extensions to a web-accessible directory and enumerate uploaded files. Runtime testing confirmed unauthenticated .txt upload and UEditor configuration disclosure; RCE, stored XSS, and the remaining extensions remain unverified. No fixed version is publicly listed.
Vulnerability mechanism
Authorization whitelist
The backend access-control filter configured in backend/config/main.php defines an allowActions array listing route prefixes exempt from authentication. The entry assets/* is a wildcard that AccessControl::isActive() matches by prefix, so any route beginning with assets/ — including assets/ueditor — is treated as whitelisted and the guest-login gate is skipped entirely.
Upload component exposure
AssetsController::actions() maps the ueditor action ID to UeditorAction, placing the UEditor upload component under the whitelisted prefix. In UeditorAction::init(), enableCsrfValidation is set to false, so POST requests to the upload action require no CSRF token. The intended trust boundary — backend authentication — is bypassed for this upload-capable action.
Extension-only validation and storage
The Uploader component validates uploads by checking only the last filename extension against fileAllowFiles, a list of 40 permitted extensions, with no MIME-type or content-type verification. Accepted files are written to frontend/web/uploads/ueditor/upload/file/, under the web root, making them retrievable via HTTP. The listfile action returns URLs and timestamps of uploaded files without authentication. The missing check is authorization: the wildcard assets/* entry, presumably intended for static asset serving, also covers the UEditor upload action through prefix matching.
Prerequisites and attack logic
The only attacker-side prerequisite is network reachability to the backend entry point. Application initialization must be complete, but that is a deployment-side condition, not an attacker action. No account, cookie, CSRF token, or user interaction is required. Once the backend is reachable, the whitelist match bypasses the authentication gate and CSRF is disabled on the action, so an unauthenticated upload proceeds to extension-only validation and web-root storage. These conditions were demonstrated on a 2.1.1 instance; equivalent configurations of other affected versions are inferred from source comparison but not dynamically tested.
Core pseudocode
function handleBackend(route, request): |
The server-side dispatch model shows the access-control gate and upload path. The decisive missing check is that accessControl.isWhitelisted returns true for assets/ueditor via the assets/* prefix match, skipping authentication before the upload-capable action is reached.
Affected scope
The CVE advisory lists the affected range as FeehiCMS up to 2.1.1. Source-code sampling confirmed the assets/* whitelist entry in versions 2.0.0, 2.0.5, 2.0.8, 2.1.0, 2.1.0.2, and 2.1.1, as well as the master branch. Version 1.0.0rc2 does not contain the entry (source comparison), bounding the lower end. Dynamic testing was performed only on 2.1.1.
Runtime-observed impact on 2.1.1: unauthenticated upload of .txt files to a web-accessible directory, HTTP retrieval of uploaded content, uploaded-file enumeration via listfile, and UEditor configuration disclosure — all without cookie or CSRF token.
Inferred but not runtime-verified: phishing or malicious-payload hosting, content pollution, and disk exhaustion. Not verified: RCE, stored XSS, SSRF, double-extension bypass, and upload of the 39 other whitelisted extensions. The .php extension is blocked by the extension whitelist (source-level only). No fixed version is publicly listed; 2.1.1 is the last upstream release and master remains affected. CVSS 3.1 = 5.3 and CVSS 4.0 = 5.5 are CNA-assigned, not independently recalculated.
Remediation and detection
The primary fix is to remove assets/* from allowActions or narrow it so it cannot match upload-capable controller actions; UEditor actions should require backend authentication. CSRF validation should not be disabled on upload actions reachable by unauthenticated routes. Upload validation should independently verify MIME type and content, not rely solely on the filename extension.
As a boundary mitigation (recommendation, not vendor-verified): restrict unauthenticated assets/* routes at the WAF or reverse-proxy layer and do not expose UEditor upload actions without authentication.
Detection leads: unauthenticated requests to UEditor config, uploadfile, and listfile actions succeeding without a cookie or CSRF token is an indicator, but requires correlation with expected traffic since legitimate asset requests may also match the prefix. Source-level inspection should check allowActions for wildcard entries covering upload-capable controllers and enableCsrfValidation=false on unauthenticated routes. No vendor-verified fix is available at the time of this analysis; upgrade guidance should be confirmed with the upstream project.