https://db.gcve.eu/sightings/feed 2026-04-30T19:51:19.600450+00:00 Vulnerability-Lookup info@gcve.eu python-feedgen Contains only the most 10 recent sightings. https://db.gcve.eu/sighting/070ba85a-c3c3-4dff-a117-26b6f5c99cc1/export 2026-04-30T19:51:19.971138+00:00 cedric http://db.gcve.eu/user/cedric {"uuid": "070ba85a-c3c3-4dff-a117-26b6f5c99cc1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-24363", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/2993", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: CVE-2025-24363\n\ud83d\udd39 Description: The HL7 FHIR IG publisher is a tool to take a set of inputs and create a standard FHIR IG. Prior to version 1.8.9, in CI contexts, the IG Publisher CLI uses git commands to determine the URL of the originating repo. If the repo was cloned, or otherwise set to use a repo that uses a username and credential based URL, the entire URL will be included in the built Implementation Guide, exposing username and credential. This does not impact users that clone public repos without credentials, such as those using the auto-ig-build continuous integration infrastructure. This problem has been patched in release 1.8.9. Some workarounds are available. Users should ensure the IG repo they are publishing does not have username or credentials included in the `origin` URL. Running the command `git remote origin url` should return a URL that contains no username, password, or token; or users should run the IG Publisher CLI with the `-repo` parameter and specify a URL that contains no username, password, or token.\n\ud83d\udccf Published: 2025-01-24T18:54:44.179Z\n\ud83d\udccf Modified: 2025-01-24T18:54:44.179Z\n\ud83d\udd17 References:\n1. https://github.com/HL7/fhir-ig-publisher/security/advisories/GHSA-6729-95v3-pjc2\n2. https://github.com/HL7/fhir-ig-publisher/commit/d968694b7dd041640efab5414d7077d5028569f7\n3. https://github.com/HL7/fhir-ig-publisher/releases/tag/1.8.9", "creation_timestamp": "2025-01-24T19:05:30.000000Z"} 2025-01-24T19:05:30+00:00 https://db.gcve.eu/sighting/92a8e806-214d-4370-a5a9-02501be35097/export 2026-04-30T19:51:19.968935+00:00 cedric http://db.gcve.eu/user/cedric {"uuid": "92a8e806-214d-4370-a5a9-02501be35097", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2025-24363", "type": "seen", "source": "https://t.me/cvedetector/16339", "content": "{\n \"Source\": \"CVE FEED\",\n \"Title\": \"CVE-2025-24363 - Cisco HL7 FHIR IG Publisher Credential Exposure\", \n \"Content\": \"CVE ID : CVE-2025-24363 \nPublished : Jan. 24, 2025, 7:15 p.m. | 38\u00a0minutes ago \nDescription : The HL7 FHIR IG publisher is a tool to take a set of inputs and create a standard FHIR IG. Prior to version 1.8.9, in CI contexts, the IG Publisher CLI uses git commands to determine the URL of the originating repo. If the repo was cloned, or otherwise set to use a repo that uses a username and credential based URL, the entire URL will be included in the built Implementation Guide, exposing username and credential. This does not impact users that clone public repos without credentials, such as those using the auto-ig-build continuous integration infrastructure. This problem has been patched in release 1.8.9. Some workarounds are available. Users should ensure the IG repo they are publishing does not have username or credentials included in the `origin` URL. Running the command `git remote origin url` should return a URL that contains no username, password, or token; or users should run the IG Publisher CLI with the `-repo` parameter and specify a URL that contains no username, password, or token. \nSeverity: 4.2 | MEDIUM \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n \"Detection Date\": \"24 Jan 2025\",\n \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-24T21:06:17.000000Z"} 2025-01-24T21:06:17+00:00