Summary
EspoCRM before 10.0.5 contains an authorization weakness in the PersonalAccount service that can expose other users' stored IMAP passwords. A user with Email Account scope access who knows a victim's Email Account record ID may retrieve credentials associated with that record and use them to access the victim's mailbox.
EspoCRM before 10.0.5 contains an authorization weakness in the PersonalAccount service that can expose other users' stored IMAP passwords. A user with Email Account scope access who knows a victim's Email Account record ID may retrieve credentials associated with that record and use them to access the victim's mailbox.
Affected context
The issue occurs in EspoCRM deployments where the PersonalAccount service processes requests for Email Account records and does not sufficiently enforce ownership or record-level authorization. The risk is present when an authenticated user has Email Account scope access, can identify another user's record ID, and the service returns sensitive IMAP credentials from that record.
The issue occurs in EspoCRM deployments where the PersonalAccount service processes requests for Email Account records and does not sufficiently enforce ownership or record-level authorization. The risk is present when an authenticated user has Email Account scope access, can identify another user's record ID, and the service returns sensitive IMAP credentials from that record.
Exploit preconditions
- Attack surface: EspoCRM's PersonalAccount service and Email Account record endpoints
- Required access: An authenticated account with Email Account scope access
- Required knowledge: The victim's Email Account record ID
- Trigger point: A request to retrieve the targeted Email Account record
- Why exploitation is possible: Record-level authorization does not adequately
bind access to the requesting user's permitted accounts, allowing sensitive
credential data to be returned
- Attack surface: EspoCRM's PersonalAccount service and Email Account record endpoints
- Required access: An authenticated account with Email Account scope access
- Required knowledge: The victim's Email Account record ID
- Trigger point: A request to retrieve the targeted Email Account record
- Why exploitation is possible: Record-level authorization does not adequately
bind access to the requesting user's permitted accounts, allowing sensitive
credential data to be returned
Why this happens
The underlying bug is an object-level authorization failure: the application uses a client-supplied record identifier to select an Email Account but does not reliably verify that the requester is authorized to access that specific record. This insecure direct object reference can expose credential material, mapping to CWE-522, Insufficiently Protected Credentials, because stored IMAP passwords become accessible outside their intended security boundary.
The underlying bug is an object-level authorization failure: the application uses a client-supplied record identifier to select an Email Account but does not reliably verify that the requester is authorized to access that specific record. This insecure direct object reference can expose credential material, mapping to CWE-522, Insufficiently Protected Credentials, because stored IMAP passwords become accessible outside their intended security boundary.
Potential impact
- An attacker may obtain another user's stored IMAP password
- The exposed credentials could allow unauthorized mailbox access
- Attackers could read, alter, or delete email messages depending on account permissions
- Mailbox access could support phishing, data theft, or further account compromise
- An attacker may obtain another user's stored IMAP password
- The exposed credentials could allow unauthorized mailbox access
- Attackers could read, alter, or delete email messages depending on account permissions
- Mailbox access could support phishing, data theft, or further account compromise
General mitigation guidance
Mitigation generally focuses on enforcing authorization for every object
access and minimizing the exposure of stored credentials.
Common defensive patterns include:
- Enforce server-side, record-level authorization based on the authenticated user and tenant
- Avoid relying on predictable or user-supplied identifiers as access controls
- Return only the minimum fields needed for the requested operation
- Do not expose stored passwords through ordinary record retrieval responses
- Prefer encrypted credential storage and managed secret references where practical
- Apply least privilege to service accounts and mailbox integrations
- Use secure-by-default policies that deny cross-account access unless explicitly permitted
Mitigation generally focuses on enforcing authorization for every object
access and minimizing the exposure of stored credentials.
Common defensive patterns include:
- Enforce server-side, record-level authorization based on the authenticated user and tenant
- Avoid relying on predictable or user-supplied identifiers as access controls
- Return only the minimum fields needed for the requested operation
- Do not expose stored passwords through ordinary record retrieval responses
- Prefer encrypted credential storage and managed secret references where practical
- Apply least privilege to service accounts and mailbox integrations
- Use secure-by-default policies that deny cross-account access unless explicitly permitted
How teams detect issues like this
Organizations can identify similar weaknesses through:
- Static analysis and code review checks for direct record lookups using request-supplied identifiers
- Review of authorization checks at service and controller boundaries
- Tests that attempt cross-user and cross-tenant access to records with valid identifiers
- API response reviews for passwords, tokens, and other sensitive fields
- Policy enforcement requiring object-level authorization before sensitive data retrieval
- Automated security testing or code-review tools that flag IDOR and credential exposure patterns
Organizations can identify similar weaknesses through:
- Static analysis and code review checks for direct record lookups using request-supplied identifiers
- Review of authorization checks at service and controller boundaries
- Tests that attempt cross-user and cross-tenant access to records with valid identifiers
- API response reviews for passwords, tokens, and other sensitive fields
- Policy enforcement requiring object-level authorization before sensitive data retrieval
- Automated security testing or code-review tools that flag IDOR and credential exposure patterns
