Which versions of openssl_encrypt are affected by EUVD-2026-60100?

The openssl_encrypt pip package (versions before 1.4.0) contains a CORS misconfiguration in key-server and telemetry-server components that allows any website to issue authenticated API requests on…. A patch is available.

How to fix or mitigate EUVD-2026-60100?

Within 24 hours, identify all deployments of openssl_encrypt and confirm which versions are in use and whether allow_origins=['*'] with allow_credentials=True is active in docker-compose.yml and .env configurations. Within 7 days, upgrade openssl_encrypt to version 1.4.0 or later across all systems and redeploy both key-server and telemetry-server components. Within 30 days, audit all CORS configurations to ensure allow_origins restricts to specific trusted domains and prohibit allow_credentials when wildcards are used.

openssl_encrypt EUVD-2026-60100

Q: What is the CVSS score of EUVD-2026-60100?

EUVD-2026-60100 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

| CVE-2026-74881 HIGH

Permissive Cross-domain Security Policy with Untrusted Domains (CWE-942)

2026-08-17 VulnCheck

GHSA-243r-jm6r-f6pp

Information Disclosure Cors Misconfiguration Openssl Encrypt Jahlives

7.1

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

6.5 MEDIUM

Attacker needs no privileges (PR:N); victim must visit a malicious page (UI:R); confidentiality impact only, no integrity or availability effect per advisory tags.

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

4.0 AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 17, 2026 - 13:14 vuln.today

Analysis Generated

Aug 17, 2026 - 13:14 vuln.today

Patch available

Aug 17, 2026 - 12:01 EUVD

CVE Published

Aug 17, 2026 - 11:04 cve.org

HIGH 7.1

DescriptionCVE.org

openssl_encrypt versions before 1.4.0 configure CORS with allow_origins set to wildcard and allow_credentials enabled to true. Attackers can create malicious websites that make authenticated cross-origin requests to the API on behalf of any user who visits them.

AnalysisAI

CORS misconfiguration in the openssl_encrypt pip package (versions before 1.4.0) enables any website to issue fully credentialed cross-origin API requests on behalf of authenticated users, exposing sensitive API responses to attacker-controlled origins. Both standalone server components - key-server and telemetry-server - ship with the maximally permissive combination of allow_origins=["*"] and allow_credentials=True as their default configuration, propagated through docker-compose.yml and .env.example. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code is known at time of analysis, though the attack pattern is a well-understood, low-complexity web exploit.

Technical ContextAI

The vulnerability (CWE-942: Permissive Cross-domain Policy with Untrusted Domains) resides in the FastAPI/Starlette CORSMiddleware configuration within two server components of the openssl_encrypt Python package (CPE: cpe:2.3:a:jahlives:openssl_encrypt:*:*:*:*:*:*:*:*). The affected code in server/key-server/app/main.py (lines 86-92) and server/telemetry-server/app/main.py (lines 23-29) applies allow_origins=["*"], allow_credentials=True, allow_methods=["*"], and allow_headers=["*"] simultaneously. The W3C Fetch specification explicitly prohibits combining a wildcard origin with allow_credentials=True, yet some framework/proxy configurations may allow this combination to function in practice, defeating the browser's same-origin policy. The insecure default is further baked into the docker-compose.yml (CORS_ORIGINS=*) and the shipped .env.example, meaning any operator deploying without explicit CORS configuration is immediately vulnerable.

RemediationAI

Upgrade the openssl-encrypt pip package to version 1.4.0 or later, which resolves the issue by changing the CORS default from ["*"] to [] in both key-server and telemetry-server and adds validation that rejects wildcard origins when debug=False (commit 809416b on branch releases/1.4.x). If an immediate upgrade is not feasible, operators must explicitly set the CORS_ORIGINS environment variable to a comma-separated allowlist of trusted origins (e.g., CORS_ORIGINS=https://app.yourdomain.com) in docker-compose.yml and any .env files, ensuring the wildcard default is never used in production. As an additional defense-in-depth measure, place the API behind a reverse proxy or WAF that enforces strict Origin header validation, or restrict the API's network exposure to trusted internal networks only - noting that network restriction alone does not eliminate the CORS risk if internal users' browsers are compromised. Full advisory and patch references: https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-c65f-x25w-62jv and https://github.com/jahlives/openssl_encrypt/commit/809416b74d2749cdcffb484cd65b057e1685cc13.