[CRITICAL] C7: Plaintext passwords sent in new-user welcome emails

[rubenvdlinde]

Severity: CRITICAL

Location: lib/Service/SymfonyEmailService.php lines 932–1046 (template rendering lines 155–172); lib/Service/SoftwareCatalogue/ContactPersonHandler.php lines 466–467

Description:
The new-user welcome email template contains {{ user.password }}, which injects the plaintext password into the email body. The password is generated at ContactPersonHandler.php:466 and passed directly into the email template.

Email is inherently unencrypted in transit. Combined with C5 (SMTP repointing), an attacker who redirects outbound mail captures every new user's plaintext password the moment the account is created.

Scenario:

1. Admin creates a new contact/user account.
2. System sends welcome email containing Password: <plaintext>.
3. Attacker (having exploited C5) or any email intermediary reads the password.
4. Attacker logs in as the new user.

Suggested fix:

• Never include credentials in email bodies.
• Send a one-time activation link with a short TTL instead.
• Remove {{ user.password }} from the email template and all related template variables.

---

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

[rubenvdlinde]

Runtime verification: REFUTED for the active flow (dormant code still present — recommend cleanup, not security fix)

Verdict: REFUTED on "plaintext passwords sent in new-user welcome emails". The {{ user.password }} template variable exists and sendUserPasswordEmail() is implemented to populate it, but no production code path calls sendUserPasswordEmail(). The actual user-creation flow uses sendUserCreationEmail() which does NOT include the password, and the welcome template (GEBRUIKER_WELCOME_TEMPLATE) explicitly tells the user "U ontvangt een apart e-mailadres met instructies voor het instellen van uw wachtwoord" — a separate email that, by virtue of the missing caller, never actually goes out.

Code analysis

1. Random password is generated in ContactPersonHandler::createUserAccount:

// lib/Service/SoftwareCatalogue/ContactPersonHandler.php:460
$randomPw = $this->_secureRandom->generate(length: 12);
$user     = $this->_userManager->createUser(uid: $username, password: $randomPw);

$randomPw is consumed by createUser and never stored in a variable that escapes this scope. It is not passed to any email-sending method.

2. Welcome email is sendUserCreationEmail (no password):

ContactPersonHandler.php:594 calls $this->sendUserCreationEmail(user: $user, objectData: $objectData).

The private sendUserCreationEmail method at line 1748 builds $userData = ['username','email','displayName','voornaam','achternaam','roles'] — no password key. This $userData is then passed to SymfonyEmailService::sendUserCreationEmail, which renders the GEBRUIKER_WELCOME_TEMPLATE. That template contains:

<li>E-mailadres: {{ user.email }}</li>
<li>Wachtwoord: U ontvangt een apart e-mailadres met instructies voor het instellen van uw wachtwoord</li>

So the welcome email is harmless — it does not contain the plaintext password and only refers to a future separate email.

3. sendUserPasswordEmail exists but has zero callers:

grep -rn "sendUserPasswordEmail" softwarecatalog/lib/

Output:

lib/Service/SymfonyEmailService.php:935: public function sendUserPasswordEmail(...)
lib/Service/SymfonyEmailService.php:1038: }//end sendUserPasswordEmail()

Only the definition. No call site in lib/, no scheduled job, no controller action invokes it. The USER_PASSWORD_TEMPLATE constant + {{ user.password }} substitution at SymfonyEmailService.php:1147-1148 therefore never fires in production.

Residual concern (not a current vulnerability)

The dormant code is a footgun: any future developer who wires sendUserPasswordEmail into the user-creation flow re-introduces the bug. The template is also there to be displayed/edited as an "Email template" in the settings UI (it appears in getEmailTemplates), which is itself reachable as @NoAdminRequired (C5-adjacent — settings exposure).

Recommendation

• Close as not-currently-exploitable, OR
• Re-scope to "remove dormant plaintext-password template" (delete USER_PASSWORD_TEMPLATE, delete sendUserPasswordEmail, delete the {{ user.password }} substitution branch, delete the userPasswordEnabled flag and its user_password_enabled IAppConfig key). Cleanup, not security ship-blocker.

Why this matters (verify-first discipline)

A static-review pass flagged the {{ user.password }} template as proof of "plaintext password in welcome emails", but runtime tracing shows the welcome email is sendUserCreationEmail (no password), and the password-bearing function sendUserPasswordEmail is uncalled. This is exactly the OR #1952 lesson: a code-read CRITICAL can be a false alarm when the caller graph is checked.

---

Verified 2026-05-27 by code reading + caller-graph analysis on lib/. No runtime exploitation possible against current code; recommend dormant-code cleanup instead of urgent security fix.

[rubenvdlinde]

REFUTED at verify-first probe — sendUserPasswordEmail has zero callers in lib/, dormant code. Removed in PR #353 to prevent future re-introduction. Template contained {{ user.password }} (plaintext credential in email body); sendUserPasswordEmail(), USER_PASSWORD_TEMPLATE, setUserPasswordEnabled(), and all userPasswordEnabled config keys deleted.