[CRITICAL] C4: IDOR DoS/account-disable — any user can disable any account including admin

[rubenvdlinde]

Severity: CRITICAL

Location: lib/Controller/ContactpersonenController.php lines 1022–1113; lib/Service/ContactpersoonService.php lines 1273–1404

Description:
POST /api/contactpersonen/{id}/disable is @NoAdminRequired with zero service-level authorisation. Any authenticated user can disable any account by ID, including the admin account. Combined with C2 (privilege escalation) this creates a permanent admin lockout: escalate to super-user, disable admin, take over the instance.

Scenario:

POST /api/contactpersonen/<admin-contact-id>/disable

Sent as any authenticated user → admin account disabled → permanent lockout.

Suggested fix:

• Gate with admin or org-admin check.
• Verify that the caller has authority over the target contact's organisation before allowing disable.

---

Source: deep team-reviewer pass 2026-05-27

[rubenvdlinde]

Runtime verification: CONFIRMED (auth flaw proven, full chain env-blocked)

Verdict: CONFIRMED on the auth gate; the disable-by-id call is reachable as any authenticated user. The full admin-lockout chain is real but requires an existing contactpersoon row mapping to the admin account, which the local dev env doesn't have.

What was verified at runtime

curl -X POST -u "swcverify-attacker:AttackerPass1234!" \
  -H "Content-Type: application/json" -H "OCS-APIRequest: true" \
  "http://localhost:8080/index.php/apps/softwarecatalog/api/contactpersonen/fake-admin-id/disable"

Response: 200 OK, X-User-Id: swcverify-attacker, {"success":false,"message":"Failed to disable user account: Object not found in magic table"}.

The non-admin attacker reaches the controller body — no auth gate. The error originates from ContactpersoonService::disableUserForContactpersoon failing to find the OR object. With a real contactpersoon id where $contactData['username'] === 'admin', the service would call $user->setEnabled(false) and disable the admin account.

Code evidence

• lib/Controller/ContactpersonenController.php:985 — disableUser() is @NoAdminRequired, calls contactSvc->disableUserForContactpersoon($contactpersoonId) with no caller-side authorisation.
• lib/Service/ContactpersoonService.php:1331-1391 — looks up the contactpersoon with _rbac:false, _multitenancy:false, reads $contactData['username'], calls $user->setEnabled(false). No check that the caller is admin, owns the organisation, or has authority over the target contact.

Chain (combined with C2 #327)

1. Attacker creates/lifts a contactpersoon whose username === 'admin' (or finds an existing one — convertToUser from C3 produces a contact-to-user mapping in OR).
2. POST disable with that contactpersoon id → admin is disabled.
3. If C2 has also been used to add the attacker's group to super_user_groups, the instance is effectively locked into the attacker's authority.

Suggested fix

Issue suggestions are correct:

• Drop @NoAdminRequired from disableUser (and enableUser at line 1023 by symmetry — same @NoAdminRequired/no-guard pattern)
• Service layer: refuse if the target username is admin/sub-admin
• Optionally: refuse if the caller is not an org-admin of the target contact's organisation
• Add an audit log entry on disable (currently only logger->info with disabled_by, no persistent audit trail)

What was NOT proven

• Actually flipping the admin account to disabled (env-blocked: no contactpersoon row mapped to admin)
• The "permanent lockout via C2 + C4 chain"

Both are environment-blocked, not refuted. The disable-anyone-by-id flaw is fully confirmed.

---

Verified runtime 2026-05-27 on local NC docker (custom_apps/softwarecatalog 0.2.0). Test users cleaned up.

[rubenvdlinde]

Fixed in #353 (squash-merged to development). All auth gates applied; see PR for per-issue detail.