{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/vendors/openhealth/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":["cpe:2.3:a:openhealth:openhealth:*:*:*:*:*:*:*:*"],"_cs_cves":[{"cvss":7.7,"id":"CVE-2026-111312"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["OpenHealth (\u003c= 0.2.0)"],"_cs_severities":["high"],"_cs_tags":[],"_cs_type":"advisory","_cs_vendors":["OpenHealth"],"content_html":"\u003cp\u003eOpenHealth versions 0.2.0 and earlier contain a critical missing authentication and authorization vulnerability in the /api/health-data/[id] endpoint. The affected handlers for GET, PATCH, and DELETE operations fail to validate user sessions or verify that the requested HealthData record belongs to the requester. An unauthenticated attacker who discovers or enumerates a valid record identifier can bypass security controls to access, alter, or destroy sensitive patient information. This vulnerability poses a significant risk to the confidentiality and integrity of medical data handled by the application. Because the flaw exists within the core API logic, it is trivial to exploit via standard HTTP requests once a valid record ID is identified.\u003c/p\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows unauthenticated attackers to exfiltrate private medical record data and metadata, overwrite existing patient records with arbitrary JSON payloads, or delete critical records entirely. This exposes patient health information to unauthorized parties and disrupts the availability of medical records, which may have legal, compliance, and clinical safety implications depending on the deployment environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade the OpenHealth application to a version released after 0.2.0 that includes patches for authentication enforcement.\u003c/li\u003e\n\u003cli\u003eAudit access logs for high volumes of 200 OK responses to GET, PATCH, or DELETE requests targeting /api/health-data/* from unauthenticated or unexpected IP sources.\u003c/li\u003e\n\u003cli\u003eImplement strict ingress filtering or network-level authentication (e.g., mTLS or API gateway validation) as a compensating control until the application can be patched.\u003c/li\u003e\n\u003cli\u003eUse the webserver logs to monitor for excessive enumerative requests against the /api/health-data/ endpoint, which may indicate an attacker attempting to discover valid record IDs.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-10-15T22:50:12Z","date_published":"2026-10-15T22:50:12Z","id":"https://feed.craftedsignal.io/briefs/2026-10-openhealth-auth-bypass/","summary":"OpenHealth versions 0.2.0 and earlier are vulnerable to unauthenticated access within the /api/health-data/ endpoint, allowing remote attackers to read, modify, or delete sensitive medical records.","title":"Authentication and Authorization Bypass in OpenHealth","url":"https://feed.craftedsignal.io/briefs/2026-10-openhealth-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed - OpenHealth","version":"https://jsonfeed.org/version/1.1"}