Summary
Leantime's JSON-RPC TwoFA methods do not adequately verify that the authenticated caller is authorized to act on the specified user account. An authenticated user may therefore retrieve another account's live TOTP secret or disable that account's two-factor authentication, weakening account protection and potentially enabling further compromise.
Affected context
The issue occurs in Leantime deployments through version 3.6.2 when the JSON-RPC dispatcher exposes the TwoFA methods getSetupData, saveSecret, verifyAndEnable, and disable2FA. Risk is present when these methods accept a caller-supplied userId without consistently enforcing ownership, session binding, or a permission attribute appropriate to the target account.
Exploit preconditions
- Attack surface: Authenticated JSON-RPC endpoints in the Leantime TwoFA service
- Required access: A valid authenticated Leantime account
- Target condition: The caller can submit a user identifier for an account they do not own
- Trigger point: Invocation of a TwoFA method that reads or changes the target account's settings
- Why exploitation is possible: Authorization checks do not reliably bind the requested user identifier to the authenticated session or an explicitly granted administrative permission
Why this happens
The underlying bug is an object-level authorization failure mapped to CWE-862: Missing Authorization. Sensitive account-management methods trust a caller-supplied userId without consistently applying ownership validation, session pinning, or a permission-attribute gate before accessing or modifying the referenced account. This creates an insecure direct object reference pattern in the JSON-RPC layer.
Potential impact
- An attacker may read another user's live TOTP secret
- An attacker may disable two-factor authentication for another account
- Account protections may be weakened or bypassed
- A compromised authenticated account could be used to target higher-privileged users
- Organizations could experience unauthorized access, privacy loss, or follow-on account compromise
General mitigation guidance
Mitigation generally centers on enforcing authorization at every sensitive RPC method rather than relying on the caller-supplied object identifier.
Common defensive patterns include:
- Binding account-management operations to the authenticated session by default
- Requiring explicit, narrowly scoped administrative permissions for cross-account actions
- Validating ownership and authorization before reading or changing any 2FA state
- Avoiding client-controlled identifiers when the target account can be derived from the session
- Applying consistent authorization middleware across all RPC endpoints
- Limiting administrative privileges and auditing sensitive 2FA operations
- Reducing the amount of secret material returned through application interfaces
How teams detect issues like this
Organizations commonly detect this class of issue through:
- Static analysis rules that identify sensitive operations using caller-controlled object identifiers
- Code review checks for missing ownership, session-binding, or permission validation
- Endpoint inventories that compare authorization requirements across related RPC methods
- Policy tests verifying that users cannot read or modify another account's security settings
- Runtime monitoring for unusual cross-account 2FA access, secret retrieval, or disablement events
- Automated security testing that exercises object-level authorization boundaries with multiple user roles
