alist-cms

The responses-career collection stores job-application PII. Its router deliberately replaces createCoreRouter to expose POST (create) and PUT /responses-careers/:id (update by primary key). The PUT route carries only a rate-limit middleware — no policy, no auth flag — and the controller is the unmodified core controller whose update() performs no per-object authorization. The records have no owner relation, so even a custom check would have nothing to bind to. Because the matching POST endpoint must be callable by the anonymous Vue frontend (which sends no auth header), the Public role almost certainly also carries the 'update' action. Strapi default primary keys are auto-increment integers, so :id is trivially enumerable. This is a textbook write-side BOLA/IDOR. Confidence is 'likely' rather than 'confirmed' only because the live up_permissions grant for the Public role lives in the runtime DB (not in this repo); the code path is fully confirmed.

Unauthenticated attacker iterates sequential :id values and overwrites any applicant's record: redirect recruiter follow-up by rewriting email/phone, swap the cv media pointer, forge jobId/jobTitle associations, or (via draftAndPublish) flip publication state. Mass integrity loss / poisoning of the recruitment PII pipeline with no authentication.

Confirmed the route, controller, schema, and total absence of any policy/ownership code. Gated on the runtime Public-role grant which is not in-repo; kept 'likely'. This is the single highest-impact issue in the repo.

Strapi v4 users-permissions auth endpoints read their rate-limit config from plugin.users-permissions.ratelimit, which config/plugins.js sets to { interval: 60000, max: 1 }. koa2-ratelimit expects interval as a duration object ({ min: 5 }) — exactly what the two working per-route middlewares in this same repo use — so the bare number 60000 is malformed and the window is coerced unpredictably. Two harms: (1) if it engages, max:1 permits a single auth request per window and self-DoSes the admin/user login; (2) the only correctly-built limiters are scoped to contact-us/responses-career and never to the credential endpoints, so there is no reliable brute-force / credential-stuffing throttle on /api/auth/*. The dead express-rate-limit policy provides none either. CLAUDE.md itself flags this config as broken.

Either denial of service of the login/admin auth path (max:1 per malformed window) or, more likely, absence of an effective brute-force/credential-stuffing control on /api/auth/local, /auth/forgot-password, /auth/reset-password and /auth/email-confirmation — letting an attacker iterate passwords and guess OTP/reset/confirmation tokens without lockout.

Confirmed config shape, the two correct middleware shapes, the override-by-spread bug, and that neither middleware is bound to auth routes. Merged the auth_jwt P1 and the ssrf_misconfig P2 koa2-ratelimit findings into this one canonical entry. Severity P1 for the brute-force gap; the self-DoS angle is the alternate manifestation of the same misconfig.

The application is entirely default Strapi: every controller/service is a stock factory, so the security posture is the framework's. The pinned line (4.14.3 in yarn.lock, 4.14.4 in package-lock.json) predates many 4.x security fixes. Applicable advisories for <=4.14.x include CVE-2024-28186 (SSRF in document/webhook handling), CVE-2024-25608 (information disclosure / returns private fields), CVE-2024-34065 (reflected XSS / path issue in admin), and CVE-2024-31218 (data exposure via populate against components/relations). Several are reachable without authentication given the public contact-us/responses-career/upload surface. Companion frontend hard-codes dev-strapi.alist.ae, so the instance is/was internet-reachable.

Depending on which patched CVE is reachable: SSRF pivot to internal services / cloud metadata (169.254.169.254), unauthenticated disclosure of private content-type fields, reflected XSS leading to admin-session takeover, and data exposure via populate. Worst realistic is admin-panel compromise of the full CMS.

Merged the two duplicate stale-Strapi findings (ssrf_misconfig 4.14.3 + supply_chain 4.14.4). Confirmed both lockfiles, the version disagreement, and that all code is default-factory. CVE-2024-25608/34065 are well-established; CVE-2024-28186 SSRF reachability is configuration-dependent so impact band kept realistic.

The resolved tree contains multiple packages with public CVEs, several directly on the internet-facing request path. axios 1.5.0 (CVE-2023-45857) and follow-redirects 1.15.3 (CVE-2024-28849) sit in server-side fetch/redirect paths; formidable 1.2.6 parses the multipart body of the public CV-upload and feeds sharp 0.32.0 for image decode; braces/micromatch (old majors present) and path-to-regexp 0.1.7 (via express) carry ReDoS. Combined with the broken rate limiting (AC-02), ReDoS and upload-decode paths are reachable unauthenticated.

ReDoS / resource-exhaustion DoS against public endpoints (compounded by the broken rate limit), SSRF and XSRF-token/credential leakage via the axios+follow-redirects chain, and memory-safety risk in the formidable->sharp upload-processing path that handles attacker-supplied files.

Confirmed every cited version against package-lock.json. Corrected the original finding's path-to-regexp evidence: the top-level package is 6.2.1, but 0.1.7 IS present nested under express, so CVE-2024-45296 stands. Folded the supply-chain transitive-deps finding here.

Every content-type route relies on Strapi defaults, and the entire access-control decision surface (which actions each of Public/Authenticated may perform on each of the 30 content types) lives exclusively in the runtime up_permissions DB table. The repo has no policies, no auth flags, no bootstrap seeding, and no committed export of the role matrix. Authorization is unversioned, unreviewable, and not reproducible across environments. A single mistake in the admin UI (enabling find/findOne for Public on a sensitive collection, or leaving a freshly-created type 'open') silently becomes a production access-control flaw with no code-review or CI gate. The single Oct-2023 commit and lack of deploy automation make drift between documented intent and live grants highly likely. This is the root cause that turns AC-01 and AC-12 from 'likely' into real exposure.

Access-control posture cannot be audited from source or enforced by code. Any operator mistake in the permissions UI directly exposes data with no safety net; environments cannot be guaranteed consistent; this review cannot definitively confirm the live grant set.

Confirmed empty bootstrap, no policies, all default routers. This is a governance/coverage finding (CWE-862) and the umbrella under which the IDOR/forced-browsing items become exploitable. Kept at P2 as the realized impact is mediated by the more specific AC-01/AC-12.

users-permissions is left at defaults: HS256 JWTs signed with JWT_SECRET and, with no jwt.expiresIn override, the stock 30-day lifetime. There is no token denylist, no logout-side invalidation, and no refresh-token rotation (no extension overrides the auth controller). The payload is a bare {id} with no aud/iss binding. A leaked/stolen token (e.g. via XSS in the paired alist-website, log leakage, shared device) stays valid up to 30 days and cannot be revoked server-side short of rotating JWT_SECRET (which kills ALL tokens). Password change does not invalidate prior tokens. Same pattern for admin sessions.

A stolen content-editor or end-user token grants persistent access for ~30 days with no single-session revocation; logout and password reset do not contain a compromise, widening the blast radius of any token leak.

Confirmed plugins.js has no jwt block and extensions is empty; stock 30-day HS256 behaviour applies. Valid hardening finding.

All crypto material (HS256 JWT_SECRET for user tokens, ADMIN_JWT_SECRET for the admin panel, API_TOKEN_SALT, TRANSFER_TOKEN_SALT, and APP_KEYS for the Koa session cookie) is sourced from env with no fallback and no entropy validation. The committed .env.example ships dictionary-word placeholders. Because the token algorithm is HS256, JWT_SECRET is also the verification key: if any placeholder reached production (a common mistake, called out in this repo's own CLAUDE.md), an attacker could brute-force/guess the HS256 secret (hashcat -m 16500 against one captured token) and forge tokens for any user, and forge admin-panel JWTs via ADMIN_JWT_SECRET for full CMS takeover. The production value is not in the repo, hence theoretical confidence.

If placeholder/weak secrets reached production: full authentication bypass via forged HS256 user tokens, admin-panel JWT forgery (complete CMS compromise), and session-cookie forgery via guessable APP_KEYS.

Confirmed placeholders in .env.example and that no real .env is committed. Theoretical because production secret values are out of repo. The 'no fallback / fail-boot' design in admin.js/server.js is good and noted.

The career endpoint accepts a required cv media with allowedTypes:['files'], which in Strapi means arbitrary file types. The upload config sets no sizeLimit and no MIME allowlist, so Strapi falls back to the ~200MB default body limit and stores files via the local provider under public/uploads/, served directly by strapi::public. The route is publicly reachable (POST, rate-limited only, and that limiter is degraded — see AC-02). An attacker can upload very large files (disk-exhaustion DoS) or dangerous-extension files (.html/.svg/.js) served same-origin, enabling stored-XSS / HTML-injection and content-type confusion. Non-image files are not renamed to opaque paths with restricted Content-Type by default.

Disk-exhaustion DoS via oversized uploads; stored XSS / HTML smuggling via .html/.svg served same-origin from public/uploads/<name>; storage abuse. Availability/integrity impact on host and visitors.

Confirmed schema allowedTypes:['files'], no sizeLimit in plugins.js, local provider + strapi::public. Folded the existing-report 'CV uploads no virus scanning' item in here.

CORS is registered with the bare default strapi::cors and no origin allowlist. Strapi 4's built-in default is Access-Control-Allow-Origin: * (methods GET,POST,PUT,DELETE,PATCH,HEAD). Any web origin can script-read responses from every exposed /api/* endpoint. The content API is bearer/JWT-based rather than cookie-based, so credentialed-CORS session theft is not directly possible (which caps severity), but the wildcard still lets arbitrary origins read all publicly-permitted CMS content and any data exposed to a leaked/embedded API token, and removes a defense-in-depth boundary. The only legitimate consumer is the alist-website Vue frontend, so an explicit allowlist is feasible.

Any third-party site can read all CORS-exposed CMS API data in a visitor's browser context; combined with a leaked API token an attacker page could read token-scoped data cross-origin. Weakens CSRF/clickjacking posture.

Confirmed bare strapi::cors and no env override. Strapi 4 default ACAO is *. Valid; severity capped by JWT (non-cookie) auth model.

package.json declares esbuild-loader ^4.0.0, but both committed lockfiles resolve 2.21.0 — the manifest was edited after the lockfiles were generated. Consequences: (1) `npm ci` aborts with EUSAGE because lock and manifest disagree, breaking reproducible/CI builds; (2) a fresh `npm install`/`yarn install` silently re-resolves esbuild-loader to whatever 4.x is latest at build time — an unpinned, never-reviewed dependency that runs as part of the admin build (strapi build), widening the supply-chain trust surface; because several packages carry hasInstallScript:true, a hijacked release would execute arbitrary code at install time. Compounding this, the repo ships two lockfiles that also disagree on the Strapi version, so the actual production dependency tree is undefined.

Builds are non-reproducible and the production dependency tree is undefined. A future malicious esbuild-loader 4.x release (or one of its deps) would be pulled automatically with no lockfile guardrail, executing in the build toolchain via lifecycle scripts. CI/dev/prod artifacts can silently diverge.

Confirmed the version mismatch in package.json vs both lockfiles. Corrected the original finding's claim that yarn.lock omits esbuild-loader — it is present as ^2.21.0. Folded the dual-lockfile/Strapi-version-disagreement and the postinstall-scripts findings here as the same software-integrity issue.

The submission endpoints use the default core create/update, which bind every non-system attribute from the request body without a server-side writable-field allowlist. For these anonymous forms an attacker controls every field including ones the frontend never surfaces (jobId/jobTitle on responses-career; company on contact-us) and can supply arbitrary/oversized values (the richtext message accepts attacker markup, feeding stored-content risk in any admin viewer). The schema constrains assignment to declared attributes (so no privilege field like 'role' exists to escalate), but the lack of an allowlist plus the unauthenticated PUT (AC-01) lets an attacker set application-meaningful fields (forge a jobId/jobTitle association) that downstream business logic trusts.

Submission metadata integrity is attacker-controlled: forged job associations, spoofed company/message content, and data-quality/poisoning of the recruitment and contact pipelines. No direct privilege escalation (no sensitive property in these schemas).

Confirmed default controllers and no sanitize/allowlist anywhere. Impact is limited because schemas have no privilege fields; kept P3. Closely related to AC-01.

A leftover debug content type `test` ships with the standard createCoreRouter, registering the full CRUD route set. It is not linked from the frontend and serves no product purpose, yet it is a live, enumerable endpoint (/api/tests, /api/tests/:id). If the Public or Authenticated role retains any grant (the default freshly-created state, or an accidental enable), it becomes an unauthenticated CRUD surface reachable by forced browsing. Read-only exposure leaks an attack surface; write exposure allows planting arbitrary records. Likely (not confirmed) because live reachability depends on the out-of-repo up_permissions grants.

Unnecessary attack surface; potential unauthenticated enumeration or data injection depending on the live grant. Low data sensitivity (debug content) but indicative of poor endpoint hygiene.

Merged the two duplicate 'test content type' findings (access_control + ssrf_misconfig). Confirmed default CRUD router and schema; reachability gated on DB grants -> likely. CWE-489 (active debug code) chosen over CWE-1059.

The two user-submission collections store personal data (job-applicant resumes plus identity/contact details, and contact-form messages) as ordinary Strapi attributes with no `private:true` flag and no application-level encryption. CV files are written in clear to public/uploads via the local provider. This is sensitive-data-at-rest with no cryptographic protection. It is standard out-of-the-box Strapi behaviour, hence hardening/informational, but it is the only PII-handling surface in the repo and is relevant under GDPR/data-protection expectations.

Any compromise yielding DB or filesystem read access (a Strapi CVE per AC-03, the upload path per AC-08, or infra exposure) discloses applicant resumes and contact PII in plaintext. Because the local provider stores uploads under the public web root, file URLs are unauthenticated once known.

Confirmed schemas have no private flag and the local provider serves from the public root. Genuine hardening/PII finding; kept P3.

src/policies/ratelimit.js implements an express-rate-limit limiter using the Strapi v3 initialize() contract and strapi.app.use(...). Strapi v4 does not load policies this way and the file is never registered against any route, so it never executes (and express middleware would not even work on Koa). Its presence — plus three competing rate-limit packages in package.json — is a maintenance hazard: a reviewer may believe a global 1-req/min limiter is enforced when it is not, masking the auth brute-force gap (AC-02). CLAUDE.md itself flags it as dead code.

Misleads operators into believing global rate limiting exists; contributes to the absence of effective brute-force protection on auth endpoints. No direct exploit.

Merged the two duplicate dead-policy findings (auth_jwt + ssrf_misconfig). Confirmed v3 shape and that nothing references it.

The middleware stack keeps default strapi::poweredBy (emits an X-Powered-By: Strapi banner that aids fingerprinting and compounds the stale-version finding AC-03) and bare strapi::security (helmet) with no explicit Strict-Transport-Security, no tightened Content-Security-Policy, and default frameguard. There is no production env override. For a public deployment this leaves header-level hardening at framework defaults and advertises the stack to attackers enumerating CVEs.

Technology/version fingerprinting accelerates targeted exploitation of the unpatched Strapi version; absence of explicit HSTS/CSP reduces defense-in-depth against TLS-stripping and injection.

Confirmed both middlewares are bare defaults with no override. Standard hardening finding; P3.

All three DB connection blocks (mysql, mysql2, postgres) default the database username AND password to the literal string 'strapi'. Unlike the JWT/admin secrets (which have no fallback and fail boot when unset), the DB password silently degrades to a publicly-known default. If an operator deploys without explicitly setting DATABASE_PASSWORD (easy, since the app still boots), the production account is protected by the well-known pair strapi:strapi. This is a hardcoded-default-credential weakness (CWE-1392), not a committed live secret.

If the DB is reachable (same host/VPC, misconfigured bind, managed DB without network ACLs) and the operator relied on the default, an attacker guessing strapi:strapi gains full read/write to all CMS content including the contact-us and responses-career PII tables. Exploitability depends entirely on DB network exposure, hence low severity in a code review.

Confirmed the literal 'strapi' fallbacks in all three blocks. Low severity, gated on DB network exposure.

Almost every content type enables draftAndPublish and uses unmodified core controllers. Strapi's default find/findOne honor the client-supplied publicationState=preview parameter, returning unpublished (draft) entries alongside published ones. If the Public role has read on these types (normal for a public marketing site reading published pages/blogs), an anonymous client can append ?publicationState=preview to retrieve draft/unpublished content (unreleased blog posts, page revisions, embargoed careers). Theoretical because it depends on the live Public read grant and on whether drafts exist.

Disclosure of unpublished marketing content, draft blog posts, or not-yet-live page copy to anonymous users, undermining embargoes and editorial workflow confidentiality.

Confirmed 30/30 draftAndPublish and default controllers. Theoretical pending live Public read grant; kept as such.