What is the CVSS score of CVE-2026-49267?

CVE-2026-49267 has a CVSS 3.1 base score of 5.9 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-49267?

Yes, a patch is available for CVE-2026-49267. Update the affected software to the latest version immediately.

Apache Airflow CVE-2026-49267

EUVD-2026-33594 MEDIUM

Improper Certificate Validation (CWE-295)

2026-05-31

GHSA-799x-qp47-8qwq

Authentication Bypass Apache Airflow

5.9

CVSS 3.1 · Vendor

Severity by source

Vendor (CNA) PRIMARY

5.9 MEDIUM

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Primary rating from Vendor (CNA) · only source for this CVE.

CVSS VectorVendor

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 02, 2026 - 17:27 vuln.today

Analysis Generated

Jun 02, 2026 - 17:27 vuln.today

CVSS changed

Jun 02, 2026 - 17:22 NVD

5.9 (MEDIUM)

Patch available

Jun 01, 2026 - 10:01 EUVD

CVE Published

May 31, 2026 - 12:45 nvd

UNKNOWN (no severity yet)

CVE Published

May 31, 2026 - 12:45 nvd

MEDIUM 5.9

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

4 pypi packages depend on apache-airflow (4 direct, 0 indirect)

Ecosystem-wide dependent count for version 2.0.0.

Description PRE-NVD

Disclosed via oss-security. NVD scoring and full description are pending.

AnalysisAI

Missing certificate validation during SMTP STARTTLS negotiation in Apache Airflow 2.0.0 through 3.2.1 exposes email traffic to man-in-the-middle interception. Both the core email utility (airflow.utils.email.send_email) and the SMTP provider hook (SmtpHook.get_conn, SmtpHook.aget_conn) called starttls() without an SSL context, causing Python's smtplib to accept any server certificate unconditionally. An unauthenticated network-adjacent attacker who can intercept traffic between the Airflow instance and its configured SMTP relay can present a fraudulent TLS certificate, successfully complete the upgrade handshake, and read all outbound email content in cleartext. No public exploit identified at time of analysis and EPSS is 0.01%, but the impact class is high confidentiality loss per CVSS.

Technical ContextAI

CWE-295 (Improper Certificate Validation) is the root cause. Python's smtplib.SMTP.starttls() accepts an optional context parameter; when called without one it creates a bare SSLContext that does not validate the server's certificate chain or hostname. The fix, introduced in PR #65346, adds a _get_ssl_context() helper (airflow-core) and _build_ssl_context() method (SMTP provider) that call ssl.create_default_context(), which validates against the system's trusted CA bundle and enforces hostname checking. Previously the email.ssl_context configuration option only governed the SMTP_SSL path; after the fix it also governs STARTTLS. Affected CPE covers Apache Airflow versions 2.0.0 through 3.2.1 (EUVD: Apache Airflow 2.0.0 < 3.2.2). Both synchronous and async SMTP code paths (get_conn and aget_conn) were vulnerable.

RemediationAI

Upgrade Apache Airflow to version 3.2.2 or later, which is the vendor-released patch addressing this vulnerability per EUVD-2026-33594. The upstream fix is confirmed in GitHub PR #65346 (https://github.com/apache/airflow/pull/65346). After upgrading, the STARTTLS path defaults to ssl.create_default_context(), validating certificates against the system CA bundle. If the deployment intentionally connects to an SMTP server using a self-signed or non-publicly-trusted certificate and upgrading immediately is not feasible, the certificate validation behavior can be preserved as a temporary workaround by setting email.ssl_context = none in airflow.cfg for core email, or by setting the ssl_context connection extra to none in the SMTP connection definition for SmtpHook - however, this explicitly disables all certificate validation and should only be used with a trusted internal SMTP relay over an already-controlled network segment, not as a permanent configuration. The trade-off is clear: setting ssl_context = none re-introduces the original vulnerability.