- Status Closed
-
Assigned To
cbay - Private
Opened by subhash - 13.08.2026
Last edited by cbay - 13.08.2026
FS#443 - Authenticated API Disclosure of DKIM Private Keys
Description
I identified a sensitive information disclosure vulnerability in the AlwaysData REST API affecting the Domain API resource.
An authenticated API user can request:
GET /v1/domain/
or an individual domain:
GET /v1/domain/{domain_id}/
and the API response contains the complete dkim_private_key value for the domain.
The response exposes the private RSA key alongside the public DKIM key. According to AlwaysData's own documentation, the DKIM private key is intended to be known only to and kept secret by the domain's mail delivery servers, while the public key is published through DNS. I validated this against my own authorized test accounts/domains and did not attempt to access or extract private keys belonging to unauthorized users.
CVSS → CVSS v3.1: 7.5 (High)
Steps to Reproduce 1. Obtain an authorized AlwaysData API token. Use an API token belonging to an account you control.AlwaysData documents API authentication using the API token followed by a colon.
2. Request the domain collection
curl -sS --basic \ --user "$APIKEY:" \ 'https://api.alwaysdata.com/v1/domain/'
3. Observe the response
The API returns domain objects containing:
{
"id": 130581,
"name": "www.dam.com",
"dkim_selector": "alwaysdata",
"dkim_public_key": "[REDACTED]",
"dkim_private_key": "[REDACTED]"
}
The actual dkim_private_key value contains a complete RSA private key.
4. Verify an individual domain
Example:
curl -sS --basic \ --user "$APIKEY:" \ 'https://api.alwaysdata.com/v1/domain/130581/'
The response again contains:
"dkim_private_key": "[REDACTED]"
5. Validation performed - The collection response returned the dkim_private_key field for 3 authorized domains. The individual domain endpoint also returned the same sensitive field.
For safety, I have not included the actual private-key material in this report.
Actual Behavior The authenticated Domain API returns the domain's complete DKIM private key in the JSON response.
The private key is exposed through:
GET /v1/domain/
GET /v1/domain/{domain_id}/
This means an API consumer with appropriate access to the domain resource can retrieve cryptographic secret material that should remain confidential.
Expected Behavior
The API should never return the DKIM private key through normal domain API responses.
If the private key is required for an administrative operation, it should remain server-side and should not be serialized into API responses.
The API response should expose only non-sensitive information such as:
{
"dkim_selector": "alwaysdata",
"dkim_public_key": "[public key]"
}
and omit:
"dkim_private_key"
Impact
The disclosed DKIM private key is cryptographic secret material used for DKIM email authentication. AlwaysData's documentation states that DKIM uses a private/public key pair and that the private key is kept secret by the mail delivery servers.
If an attacker obtains a valid DKIM private key for a domain and can use it appropriately, they may potentially be able to generate DKIM signatures associated with that domain.
This could undermine the trust provided by DKIM and potentially facilitate convincing domain-authenticated email activity.
The vulnerability therefore represents confidentiality loss of cryptographic credentials.
Business Impact
Potential business impact includes:
1- Exposure of customers' cryptographic signing secrets.
2- Potential compromise of email-authentication trust for affected domains.
3- Increased risk of domain impersonation/phishing scenarios.
4- Potential reputational damage to customers whose domains are affected.
5- Requirement to regenerate/revoke affected DKIM keys.
6- Incident-response and customer-notification costs if production keys are exposed.
Remediation 1- Remove dkim_private_key from all API responses.
2- Return only the DKIM public key and selector where required.
3- Keep private DKIM keys exclusively server-side.
4- Review the serializer/schema for the /v1/domain/ resource and individual domain endpoint.
5- Audit API permissions to ensure private cryptographic material cannot be retrieved through any other endpoint.
6- Rotate/regenerate all DKIM private keys that were exposed, because previously exposed keys should be considered compromised.
7- Review API and application logs to determine whether sensitive keys were accessed by unauthorized parties.
PoC Kindly check attachments
Conclusion
The AlwaysData Domain API currently exposes complete DKIM private keys to authenticated API clients through both the domain collection and individual-domain endpoints.
I confirmed the issue using only accounts and domains under my control and did not attempt to access other customers' private information.
The exposed value is a genuine cryptographic private key rather than merely metadata or a public DKIM record. This creates a significant confidentiality risk and should be remediated by removing the private key from API responses and rotating affected DKIM credentials.
Thanks
Add regression tests ensuring secret fields such as private keys are never serialized in normal API responses.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Screenshot From 2026-08-13 15...
Hello,
There's no vulnerability here. Our clients have the right to see the private DKIM key we generated for them.
Kind regards,
Cyril