GHSA-C65F-X25W-62JV
Vulnerability from github – Published: 2026-04-01 21:12 – Updated: 2026-04-01 21:12
VLAI
Summary
openssl-encrypt has CORS wildcard with allow_credentials=True in standalone servers
Details
Summary
Both standalone servers configure CORS with allow_origins=["*"], allow_credentials=True, allow_methods=["*"], and allow_headers=["*"].
Affected Code
# server/key-server/app/main.py:86-92
# server/telemetry-server/app/main.py:23-29
app.add_middleware(
CORSMiddleware,
allow_origins=settings.cors_origins, # defaults to ["*"]
allow_credentials=True,
allow_methods=["*"],
allow_headers=["*"],
)
The docker-compose file (openssl_encrypt_server/docker-compose.yml:75) also defaults CORS_ORIGINS to *, and .env.example ships with CORS_ORIGINS=*.
Impact
This is the most permissive CORS configuration possible, allowing any website to make fully credentialed cross-origin requests to the API. An attacker's website could make authenticated API calls on behalf of any user who visits it.
Recommended Fix
- Remove wildcard defaults — require explicit origin configuration
- Never combine
allow_origins=["*"]withallow_credentials=True - Update
.env.examplewith placeholder domains instead of*
Fix
Fixed in commit 809416b on branch releases/1.4.x — changed CORS default from ["*"] to [] in both key-server and telemetry-server; added validation rejecting wildcard when debug=False.
Severity
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "openssl-encrypt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:12:37Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nBoth standalone servers configure CORS with `allow_origins=[\"*\"]`, `allow_credentials=True`, `allow_methods=[\"*\"]`, and `allow_headers=[\"*\"]`.\n\n### Affected Code\n\n```python\n# server/key-server/app/main.py:86-92\n# server/telemetry-server/app/main.py:23-29\napp.add_middleware(\n CORSMiddleware,\n allow_origins=settings.cors_origins, # defaults to [\"*\"]\n allow_credentials=True,\n allow_methods=[\"*\"],\n allow_headers=[\"*\"],\n)\n```\n\nThe docker-compose file (`openssl_encrypt_server/docker-compose.yml:75`) also defaults `CORS_ORIGINS` to `*`, and `.env.example` ships with `CORS_ORIGINS=*`.\n\n### Impact\n\nThis is the most permissive CORS configuration possible, allowing any website to make fully credentialed cross-origin requests to the API. An attacker\u0027s website could make authenticated API calls on behalf of any user who visits it.\n\n### Recommended Fix\n\n- Remove wildcard defaults \u2014 require explicit origin configuration\n- Never combine `allow_origins=[\"*\"]` with `allow_credentials=True`\n- Update `.env.example` with placeholder domains instead of `*`\n\n### Fix\n\nFixed in commit `809416b` on branch `releases/1.4.x` \u2014 changed CORS default from [\"*\"] to [] in both key-server and telemetry-server; added validation rejecting wildcard when debug=False.",
"id": "GHSA-c65f-x25w-62jv",
"modified": "2026-04-01T21:12:37Z",
"published": "2026-04-01T21:12:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-c65f-x25w-62jv"
},
{
"type": "WEB",
"url": "https://github.com/jahlives/openssl_encrypt/commit/809416b74d2749cdcffb484cd65b057e1685cc13"
},
{
"type": "PACKAGE",
"url": "https://github.com/jahlives/openssl_encrypt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "openssl-encrypt has CORS wildcard with allow_credentials=True in standalone servers"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…