Enviar #911886: simalexan api-lambda-send-email-ses Git commit bda6869aa81371d1e872242e74fe7d953edb818d and earlier Missing Authentication

simalexan api-lambda-send-email-ses contains a missing authentication vulnerability in its public POST /send API Gateway endpoint.

The default AWS SAM template exposes the email-sending Lambda function through a public API Gateway route without an authorizer, IAM authentication, API key requirement, or restrictive API Gateway resource policy. An unauthenticated remote caller who discovers the deployed API URL can submit caller-controlled recipient addresses, subject text, message content, carbon-copy addresses, and reply-to addresses. The Lambda function processes the supplied data and invokes Amazon SES using its execution role.

This creates a direct serverless abuse chain from an unauthenticated Internet request to an authenticated AWS SES SendEmail operation.

Affected files

template.yml
index.js
process-response.js

Vulnerability class

CWE-306: Missing Authentication for Critical Function

Root cause

The AWS SAM template declares a public API Gateway event similar to the following:

Events:
EmailApi:
Type: Api
Properties:
Path: /send
Method: POST

The event does not define an authorizer or another authentication mechanism. The resulting API Gateway endpoint can therefore be invoked without credentials.

The application also does not perform an application-level authorization check inside the Lambda function. Although the CORS response permits headers including Authorization and X-Api-Key, the presence of these names in the Access-Control-Allow-Headers response does not enforce authentication. The application does not validate either header before processing a request.

The Lambda execution role receives Amazon SES permissions through the AWS SAM SESCrudPolicy policy template. The Lambda code parses event.body and passes caller-controlled message parameters to SES.sendEmail().

Attacker-controlled parameters include:

toEmails
ccEmails
replyToEmails
subject
message

The sender identity is configured by the deployed application, but the email recipients and email content are supplied by the unauthenticated caller.

Attack scenario

An attacker obtains or discovers the deployed API Gateway URL. API Gateway endpoints may be exposed through application JavaScript, documentation, logs, browser traffic, deployment output, source code, DNS records, or other operational information.

The attacker sends an unauthenticated HTTP POST request to /send containing one or more recipient addresses and attacker-controlled message content.

API Gateway invokes the Lambda function without requiring the caller to authenticate.

The Lambda function parses the request body and constructs an Amazon SES SendEmail request.

The function invokes SES using its trusted AWS Lambda execution role.

Amazon SES processes the message under the configured and verified sender identity.

As a result, the external attacker indirectly uses the AWS account's trusted SES identity and quotas without possessing AWS or SES credentials.

Proof of concept

The issue was validated in an authorized AWS test environment using an unauthenticated request similar to the following:

curl -i -X POST "<API_URL>/send" \
-H "Content-Type: application/json" \
-d '{
"toEmails": ["<AUTHORIZED_TEST_RECIPIENT>"],
"subject": "Security validation - unauthenticated send",
"message": "This is an authorized security validation email."
}'

No Authorization header, API key, AWS Signature Version 4 credentials, session cookie, or other authentication material was included.

The endpoint returned:

HTTP/2 204

The corresponding Lambda execution was recorded in CloudWatch logs. Amazon SES accepted the send operation and returned a MessageId during controlled testing.

This confirms that an unauthenticated remote request can cause the application Lambda to perform an authenticated SES email-sending operation.

SES restrictions

The effective delivery scope depends on the victim AWS account's SES configuration.

While an SES account remains in the sandbox, destination addresses generally remain subject to SES sandbox verification restrictions. In an SES production account, SES may deliver to unverified recipient addresses.

The SESCrudPolicy IdentityName value restricts the SES identity the Lambda is authorized to use. It should not be treated as an application-level recipient allowlist. Consequently, deployments operating outside the SES sandbox may expose a substantially larger abuse surface.

Security impact

An unauthenticated attacker may be able to:

Send attacker-controlled email through the victim's trusted SES identity
Send attacker-controlled subject and message content
Send HTML email content
Select recipient, carbon-copy, and reply-to addresses
Use the trusted sender identity for spam or phishing
Consume the victim's SES sending quota
Consume Lambda and API Gateway requests
Generate CloudWatch log ingestion and storage costs
Cause SES bounce and complaint events
Damage the reputation of the configured sender identity or domain
Cause AWS to throttle, suspend, or review the victim's SES sending capability
Interfere with legitimate email delivery by exhausting quotas or reducing sender reputation

If the configured sender uses a trusted organizational domain, recipients may place greater trust in malicious messages sent through the vulnerable endpoint.

Missing abuse controls increase the impact. The application does not enforce an application-level recipient allowlist, sender-to-recipient authorization policy, rate limit, per-user quota, maximum recipient count, maximum subject length, maximum message length, or controlled server-side email template.

Input validation

The application verifies only a limited subset of the supplied data. It does not adequately enforce:

Authentication of the caller
Authorization to send email
Allowed recipient addresses or domains
Maximum number of recipients
Email address format
Maximum subject length
Maximum message length
Maximum request frequency
Server-controlled email templates
Restrictions on attacker-controlled HTML
Safe handling of malformed JSON

Malformed JSON is parsed without adequate exception handling and may also generate Lambda errors and unnecessary resource consumption.

Preconditions

The deployed API Gateway URL must be reachable by the attacker.

The default unauthenticated API configuration must not have been protected externally by the deployer.

The Lambda function and its SES execution permissions must be operational.

The sender identity must be usable under the victim's SES configuration.

Actual delivery is subject to the victim account's SES sandbox status, sending quotas, identity verification state, suppression list, and other SES controls.

Expected behavior

The POST /send endpoint should require authentication and authorization before invoking the Lambda email-sending workflow.

Authenticated callers should only be permitted to send approved message templates to recipients allowed by an explicit application policy.

The public HTTP caller should not be able to directly control all security-sensitive SES message parameters.

Remediation

Require authentication on POST /send using an API Gateway JWT authorizer, Cognito authorizer, Lambda authorizer, or AWS IAM Signature Version 4 authentication.

Perform server-side authorization after identifying the caller.

Do not rely on CORS headers, the presence of an Authorization header name, or an API key alone as an authorization control.

Implement an explicit recipient and domain allowlist appropriate to the application's intended use.

Use server-controlled email templates and permit callers to provide only narrowly defined template variables.

Restrict or sanitize HTML email content.

Limit the maximum number of To, CC, and Reply-To addresses.

Limit the maximum subject, message, and request-body sizes.

Configure API Gateway throttling, per-client quotas, AWS WAF rate-based rules, and Lambda reserved concurrency.

Monitor SES sending volume, bounce rate, complaint rate, reputation status, and unexpected recipient domains.

Generate CloudWatch alarms for abnormal invocation and delivery patterns.

Return HTTP 400 for malformed JSON and invalid message parameters.

Use the minimum required SES actions instead of a broader CRUD policy where possible.

Disclosure status

The issue was publicly reported to the project maintainer through GitHub issue number 9.

• Fuente: ⚠️ https://github.com/simalexan/api-lambda-send-email-ses/issues/9
• Usuario: changli (UID 99220)
• Sumisión: 2026-07-31 11:59 (hace 1 mes)
• Moderación: 2026-09-12 11:23 (1 month later)
• Estado: Aceptado
• Entrada de VulDB: 403100 [simalexan api-lambda-send-email-ses hasta bda6869aa81371d1e872242e74fe7d953edb818d API Gateway Endpoint template.yml SES.sendEmail toEmails/ccEmails/replyToEmails/subject/message autenticación débil]
• Puntos: 20