GCVE-1988-2026-0465

Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
Title
[0day-rubbish] Advantech WebAccess Node 9.2.3 unauthenticated CrystalRpt.aspx file upload and path traversal to code execution in w3wp.exe (9.8)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in Advantech WebAccess Node 9.2.3, the closed-source industrial SCADA/HMI web server from Advantech (Taiwan). Type: unrestricted file upload (CWE-434) compounded by path traversal (CWE-22), on a page that performs no authorization decision at all (CWE-306). CWE-73 and CWE-862 also map; CWE-250/CWE-269 apply conditionally where the pool runs at high privilege. In the WaCrpt ASP.NET Web Forms application served under /broadweb/WaCrpt/, the fileSubmit_Click handler in bin\WaCrpt.dll concatenates two attacker-supplied form fields into Server.MapPath("~/report/" + projName + "_" + nodeName + "/"), gates the result on nothing but Directory.Exists(rptDirPath), then calls FileUpload1.SaveAs(filePath) with no extension validation - and does so before it attempts to open the file as a Crystal Report. Reordering those two calls alone would break the chain. The traversal rides in nodeName rather than in the uploaded filename, because ASP.NET already strips any client-side directory from the multipart filename. Sending nodeName = \..\..\ normalises the destination to the WaCrpt application root, a directory that always exists, so the provisioning check is satisfied with no report project created and no report directory present; ASP.NET request validation inspects for HTML-dangerous sequences and not for backslash or dot-dot, so nothing filters it. The bound is exactly two dot-dot levels - three or more are refused with HttpException "Cannot use a leading .. to exit above the top directory". The chain is three HTTP requests plus a follow-on GET. Request 1 harvests __VIEWSTATE (1056 bytes) and __EVENTVALIDATION (92 bytes) while establishing the traversed destination. Request 2 posts a 510-byte ASP.NET page as FileUpload1 with fileSubmit=Upload; SaveAs writes it into the application root, ReportDocument.Load then throws and the server returns HTTP 500 - a red herring, since the write already completed. Request 3 GETs the written page, which the build manager compiles on first request and executes inside w3wp.exe, running cmd.exe /c with captured stdout. No credentials, no user interaction, no race window, no memory corruption, no prior server state. A User-Agent header is mandatory: without one the CrystalDecisions viewer control throws a NullReferenceException, the form never renders and the chain stalls at step 1 - a trap that makes an unaffected conclusion easy to reach wrongly. Authentication. No authorization decision exists anywhere in the application, and that half is artifact-proven: Page_Load performs no session, cookie, token or principal check and carries no auth filter, and its failure branch is a Response.Redirect to the login page - a navigation aid, not an access denial. The shipped WaCrpt Web.config declares an authentication mode but has no authorization deny rule and no custom authentication module; there is no global.asax in the directory; eight sibling files in the module call a session-existence check and CrystalRpt.cs is not among them. The omission signature is decisive: addTemplate.cs, the SECOND report-upload handler in the same module, enforces a case-insensitive .RPT comparison while CrystalRpt.cs enforces nothing. The product has a working mechanism - waconfig90 controllers carry an auth filter with session plus csrfToken validation - and this page is not enrolled in it. The one gap, stated as a gap: whether IIS delivers an anonymous request to the WaCrpt application path lives in the site's applicationHost.config, and no such excerpt, no installer-authored IIS fragment and no vendor documentation of that factory setting was obtained. PR:N is published on a structural argument plus lab reproduction, not on an extracted artifact - the product's own operator login page cannot function unless the hosting site accepts anonymous requests, and it is served by the same IIS site. An administrator who disabled anonymous authentication on that path, or fronted it with an authenticating gateway, is not exposed on this vector, and the conditional score below prices exactly that. Scoring. All three readings the analysis priced are published: - PRIMARY, 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - CONDITIONAL, 8.8 High, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, applying where IIS authentication is enforced on the WaCrpt application path or an authenticating gateway fronts it; nothing else in the finding changes. - REJECTED, 8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, considered because the traversal depth and the mandatory User-Agent are non-obvious and rejected because both are fixed constants under the attacker's control, which is not the CVSS 3.1 meaning of AC:H. Scope is Unchanged deliberately: the compromise executes as the pool identity of the vulnerable product's own web application, so the gain crosses a privilege level, not a component's security scope. S:C on the same impact values would compute to 10.0 and is not claimed. On scoring accuracy: the primary vector computes to ISS 0.914816, Impact under S:U of 5.873119, Exploitability 3.887043 and base 9.760161495, which the CVSS 3.1 Roundup rule renders as 9.8. The figure the research record carried for this finding is the figure its own vector computes, so no correction was required. We say so because several earlier advisories in this repository carried recorded scores that did not compute for their recorded vectors; those are being recomputed rather than copied. Impact. Confidentiality High: full read of the product's configuration, the SCADA project tree it serves and database connection material - these nodes routinely hold the point list, alarm configuration and historian data for the monitored process. Integrity High: a generic write primitive placing an attacker-named file with attacker-chosen content into a served, script-executing directory, plus arbitrary command execution, making product binaries, configuration, the report tree, tag and alarm data and host state modifiable; manipulation of served HMI content, tag values and alarm thresholds is why this is an operational-technology incident and not only a web-application one. Availability High: the web tier, the SCADA runtime it fronts and the host can be stopped or corrupted, removing operator visibility of the monitored process even where the controlled process keeps running. Execution identity caveat. The verified identity was nt authority\system with SeTcbPrivilege, SeDebugPrivilege, SeImpersonatePrivilege and SeBackupPrivilege enabled - the full SYSTEM set - but that was the VERIFICATION application pool, configured in the lab as LocalSystem. No shipped pool identity is asserted: the installer binds broadweb to DefaultAppPool and a separate helper writes the pool's IdentityType at install time, a value that could not be resolved from static strings. The rating does not depend on it, since C:H/I:H/A:H are assessed on the code-execution primitive itself. Relationship to previously published work. A previously published advisory covers an unrestricted file upload on this product scored 8.8 with AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - PR:L, an authenticated caller - affecting 9.2.1 with a fix in 9.2.2, and it does not name the affected endpoint. This finding is PR:N, and the unvalidated sink was confirmed by decompilation in 9.2.3, after that fix. Two readings are consistent with the evidence and the advisory does not pretend to settle between them: either the earlier fix addressed a different upload path and CrystalRpt.aspx was never covered, making this an independent unauthenticated variant, or the fix did not close the unauthenticated route into the same code, making this an incomplete-fix variant. Without a byte-level diff between 9.2.2 and 9.2.3, overlap cannot be excluded to certainty, and the advisory says so rather than claiming more novelty than the evidence carries. Verification boundary, stated plainly. Everything dynamic was produced by deploying the shipped WaCrpt application - CrystalRpt.aspx (2381 bytes), Web.config and bin\WaCrpt.dll, the shipped files as documented in the research record, used without modification - into a real IIS site and driving it over HTTP on loopback. The whole request path is genuine: IIS request handling, the Web Forms pipeline, event dispatch into fileSubmit_Click, Server.MapPath normalisation, FileUpload.SaveAs, the build manager compiling a freshly written page and process creation in w3wp.exe. A complete default installation of WebAccess Node 9.2.3 was NOT achieved: the 1.9 GB self-extracting installer hung in Session 0 and never produced a stock, vendor-configured deployment, so the test was surgical rather than end-to-end. Three consequences are carried explicitly. First, the site configuration was authored in the lab rather than read from the installer and the application was served at the site root over loopback, so the /broadweb/WaCrpt/ prefix is derived from a literal inside the decompiled Page_Load - the Response.Redirect to /broadweb/user/signinonly.asp - plus the application's placement in the distribution, and is strong inference rather than an observed request against a stock install. Second, the SYSTEM identity was the lab pool's; the shipped site binding, shipped pool identity and interaction with the rest of the product were never observed at runtime. Third, the record documents the installer and its size and an unpacked deployment archive holding those files and asserts they are the real product's, but does not log the extraction step, so no end-to-end provenance chain is claimed - what is asserted is that nothing in them was altered for the test. Three accommodations modified the hosting environment, not the vulnerable code: CrystalDecisions assembly redirects to match the lab host's GAC, a log4net copy from the legacy GAC_32 location, and the LocalSystem pool identity. Also not exercised: no interaction with the rest of the product; no network-path test, every request having traversed loopback from one Windows host with no firewall, reverse proxy, WAF or TLS terminator in between; no GET-only variant of request 1; no overwrite test, no non-page payload and no persistence test; no privilege enumeration under a restricted pool. What is nevertheless established at strength: two independent client implementations with two independently written payloads of different sizes (510 and 450 bytes) and different leaf names produced the same result, corroborated from the target filesystem and the IIS W3C log rather than from client responses alone - the written page sat in the application root at exactly 510 bytes, byte-identical to what was transmitted, with an on-disk timestamp matching the logged POST, and the log shows the two POSTs returning 200 then 500 immediately followed by a 200 for the uploaded file. An attacker-chosen marker was echoed and a second, unrelated binary invoked on the same command line. An independent adversarial review attacked the chain from seven angles and did not refute it; only the execution-identity angle returned partially confirmed. A separate re-analysis pass over the same decompiled sources independently returned CONFIRMED. Also recorded in the advisory, from the same exhaustion pass over the web tier: a genuine SQL injection in the unauthenticated /Login operation of the product's WCF mobile service, which does NOT escalate to code execution because that path's backend is a Microsoft Access .mdb offering no xp_cmdshell or comparable OLE-automation primitive, and the SQL Server SQLEXPRESS instance elsewhere in the product is not reached from it. Affected-version statement: 9.2.3 is the only release whose binaries were decompiled and exercised; other versions were not enumerated and no cross-version byte comparison was performed. Validate your own build. Remediation is set out in the advisory in priority order and reduces to: validate the extensio
Severity
No CVSS data available.
CWE
Assigner
VULNARCHIVE GNA GNA-1988
GNA scorecard E 38/100 over 556 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
N/A Advantech Webaccess Node Affected: unknown
Create a notification for this product.
Credits
disclosure via Fulldisclosure
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Advantech Webaccess Node",
          "vendor": "N/A",
          "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 Advantech\nWebAccess Node 9.2.3, the closed-source industrial SCADA/HMI web server from\nAdvantech (Taiwan).\n\nType: unrestricted file upload (CWE-434) compounded by path traversal (CWE-22), on\na page that performs no authorization decision at all (CWE-306). CWE-73 and CWE-862\nalso map; CWE-250/CWE-269 apply conditionally where the pool runs at high\nprivilege. In the WaCrpt ASP.NET Web Forms application served under\n/broadweb/WaCrpt/, the fileSubmit_Click handler in bin\\WaCrpt.dll concatenates two\nattacker-supplied form fields into\nServer.MapPath(\"~/report/\" + projName + \"_\" + nodeName + \"/\"), gates the result on\nnothing but Directory.Exists(rptDirPath), then calls FileUpload1.SaveAs(filePath)\nwith no extension validation - and does so before it attempts to open the file as a\nCrystal Report. Reordering those two calls alone would break the chain.\n\nThe traversal rides in nodeName rather than in the uploaded filename, because\nASP.NET already strips any client-side directory from the multipart filename.\nSending nodeName = \\..\\..\\ normalises the destination to the WaCrpt application\nroot, a directory that always exists, so the provisioning check is satisfied with no\nreport project created and no report directory present; ASP.NET request validation\ninspects for HTML-dangerous sequences and not for backslash or dot-dot, so nothing\nfilters it. The bound is exactly two dot-dot levels - three or more are refused with\nHttpException \"Cannot use a leading .. to exit above the top directory\".\n\nThe chain is three HTTP requests plus a follow-on GET. Request 1 harvests\n__VIEWSTATE (1056 bytes) and __EVENTVALIDATION (92 bytes) while establishing the\ntraversed destination. Request 2 posts a 510-byte ASP.NET page as FileUpload1 with\nfileSubmit=Upload; SaveAs writes it into the application root, ReportDocument.Load\nthen throws and the server returns HTTP 500 - a red herring, since the write already\ncompleted. Request 3 GETs the written page, which the build manager compiles on first\nrequest and executes inside w3wp.exe, running cmd.exe /c with captured stdout. No\ncredentials, no user interaction, no race window, no memory corruption, no prior\nserver state. A User-Agent header is mandatory: without one the CrystalDecisions\nviewer control throws a NullReferenceException, the form never renders and the chain\nstalls at step 1 - a trap that makes an unaffected conclusion easy to reach wrongly.\n\nAuthentication. No authorization decision exists anywhere in the application, and\nthat half is artifact-proven: Page_Load performs no session, cookie, token or\nprincipal check and carries no auth filter, and its failure branch is a\nResponse.Redirect to the login page - a navigation aid, not an access denial. The\nshipped WaCrpt Web.config declares an authentication mode but has no authorization\ndeny rule and no custom authentication module; there is no global.asax in the\ndirectory; eight sibling files in the module call a session-existence check and\nCrystalRpt.cs is not among them. The omission signature is decisive: addTemplate.cs,\nthe SECOND report-upload handler in the same module, enforces a case-insensitive\n.RPT comparison while CrystalRpt.cs enforces nothing. The product has a working\nmechanism - waconfig90 controllers carry an auth filter with session plus csrfToken\nvalidation - and this page is not enrolled in it.\n\nThe one gap, stated as a gap: whether IIS delivers an anonymous request to the\nWaCrpt application path lives in the site\u0027s applicationHost.config, and no such\nexcerpt, no installer-authored IIS fragment and no vendor documentation of that\nfactory setting was obtained. PR:N is published on a structural argument plus lab\nreproduction, not on an extracted artifact - the product\u0027s own operator login page\ncannot function unless the hosting site accepts anonymous requests, and it is served\nby the same IIS site. An administrator who disabled anonymous authentication on that\npath, or fronted it with an authenticating gateway, is not exposed on this vector,\nand the conditional score below prices exactly that.\n\nScoring. All three readings the analysis priced 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\n- CONDITIONAL, 8.8 High, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, applying\n  where IIS authentication is enforced on the WaCrpt application path or an\n  authenticating gateway fronts it; nothing else in the finding changes.\n- REJECTED, 8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, considered\n  because the traversal depth and the mandatory User-Agent are non-obvious and\n  rejected because both are fixed constants under the attacker\u0027s control, which is\n  not the CVSS 3.1 meaning of AC:H.\nScope is Unchanged deliberately: the compromise executes as the pool identity of the\nvulnerable product\u0027s own web application, so the gain crosses a privilege level, not\na component\u0027s security scope. S:C on the same impact values would compute to 10.0\nand is not claimed.\n\nOn scoring accuracy: the primary vector computes to ISS 0.914816, Impact under S:U of\n5.873119, Exploitability 3.887043 and base 9.760161495, which the CVSS 3.1 Roundup\nrule renders as 9.8. The figure the research record carried for this finding is the\nfigure its own vector computes, so no correction was required. We say so because\nseveral earlier advisories in this repository carried recorded scores that did not\ncompute for their recorded vectors; those are being recomputed rather than copied.\n\nImpact. Confidentiality High: full read of the product\u0027s configuration, the SCADA\nproject tree it serves and database connection material - these nodes routinely hold\nthe point list, alarm configuration and historian data for the monitored process.\nIntegrity High: a generic write primitive placing an attacker-named file with\nattacker-chosen content into a served, script-executing directory, plus arbitrary\ncommand execution, making product binaries, configuration, the report tree, tag and\nalarm data and host state modifiable; manipulation of served HMI content, tag values\nand alarm thresholds is why this is an operational-technology incident and not only\na web-application one. Availability High: the web tier, the SCADA runtime it fronts\nand the host can be stopped or corrupted, removing operator visibility of the\nmonitored process even where the controlled process keeps running.\n\nExecution identity caveat. The verified identity was nt authority\\system with\nSeTcbPrivilege, SeDebugPrivilege, SeImpersonatePrivilege and SeBackupPrivilege\nenabled - the full SYSTEM set - but that was the VERIFICATION application pool,\nconfigured in the lab as LocalSystem. No shipped pool identity is asserted: the\ninstaller binds broadweb to DefaultAppPool and a separate helper writes the pool\u0027s\nIdentityType at install time, a value that could not be resolved from static\nstrings. The rating does not depend on it, since C:H/I:H/A:H are assessed on the\ncode-execution primitive itself.\n\nRelationship to previously published work. A previously published advisory covers an\nunrestricted file upload on this product scored 8.8 with\nAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - PR:L, an authenticated caller - affecting\n9.2.1 with a fix in 9.2.2, and it does not name the affected endpoint. This finding\nis PR:N, and the unvalidated sink was confirmed by decompilation in 9.2.3, after that\nfix. Two readings are consistent with the evidence and the advisory does not pretend\nto settle between them: either the earlier fix addressed a different upload path and\nCrystalRpt.aspx was never covered, making this an independent unauthenticated\nvariant, or the fix did not close the unauthenticated route into the same code,\nmaking this an incomplete-fix variant. Without a byte-level diff between 9.2.2 and\n9.2.3, overlap cannot be excluded to certainty, and the advisory says so rather than\nclaiming more novelty than the evidence carries.\n\nVerification boundary, stated plainly. Everything dynamic was produced by deploying\nthe shipped WaCrpt application - CrystalRpt.aspx (2381 bytes), Web.config and\nbin\\WaCrpt.dll, the shipped files as documented in the research record, used without\nmodification - into a real IIS site and driving it over HTTP on loopback. The whole\nrequest path is genuine: IIS request handling, the Web Forms pipeline, event\ndispatch into fileSubmit_Click, Server.MapPath normalisation, FileUpload.SaveAs, the\nbuild manager compiling a freshly written page and process creation in w3wp.exe.\n\nA complete default installation of WebAccess Node 9.2.3 was NOT achieved: the 1.9 GB\nself-extracting installer hung in Session 0 and never produced a stock,\nvendor-configured deployment, so the test was surgical rather than end-to-end. Three\nconsequences are carried explicitly. First, the site configuration was authored in\nthe lab rather than read from the installer and the application was served at the\nsite root over loopback, so the /broadweb/WaCrpt/ prefix is derived from a literal\ninside the decompiled Page_Load - the Response.Redirect to\n/broadweb/user/signinonly.asp - plus the application\u0027s placement in the\ndistribution, and is strong inference rather than an observed request against a stock\ninstall. Second, the SYSTEM identity was the lab pool\u0027s; the shipped site binding,\nshipped pool identity and interaction with the rest of the product were never\nobserved at runtime. Third, the record documents the installer and its size and an\nunpacked deployment archive holding those files and asserts they are the real\nproduct\u0027s, but does not log the extraction step, so no end-to-end provenance chain is\nclaimed - what is asserted is that nothing in them was altered for the test. Three\naccommodations modified the hosting environment, not the vulnerable code:\nCrystalDecisions assembly redirects to match the lab host\u0027s GAC, a log4net copy from\nthe legacy GAC_32 location, and the LocalSystem pool identity.\n\nAlso not exercised: no interaction with the rest of the product; no network-path\ntest, every request having traversed loopback from one Windows host with no\nfirewall, reverse proxy, WAF or TLS terminator in between; no GET-only variant of\nrequest 1; no overwrite test, no non-page payload and no persistence test; no\nprivilege enumeration under a restricted pool.\n\nWhat is nevertheless established at strength: two independent client implementations\nwith two independently written payloads of different sizes (510 and 450 bytes) and\ndifferent leaf names produced the same result, corroborated from the target\nfilesystem and the IIS W3C log rather than from client responses alone - the written\npage sat in the application root at exactly 510 bytes, byte-identical to what was\ntransmitted, with an on-disk timestamp matching the logged POST, and the log shows\nthe two POSTs returning 200 then 500 immediately followed by a 200 for the uploaded\nfile. An attacker-chosen marker was echoed and a second, unrelated binary invoked on\nthe same command line. An independent adversarial review attacked the chain from\nseven angles and did not refute it; only the execution-identity angle returned\npartially confirmed. A separate re-analysis pass over the same decompiled sources\nindependently returned CONFIRMED.\n\nAlso recorded in the advisory, from the same exhaustion pass over the web tier: a\ngenuine SQL injection in the unauthenticated /Login operation of the product\u0027s WCF\nmobile service, which does NOT escalate to code execution because that path\u0027s\nbackend is a Microsoft Access .mdb offering no xp_cmdshell or comparable\nOLE-automation primitive, and the SQL Server SQLEXPRESS instance elsewhere in the\nproduct is not reached from it.\n\nAffected-version statement: 9.2.3 is the only release whose binaries were decompiled\nand exercised; other versions were not enumerated and no cross-version byte\ncomparison was performed. Validate your own build.\n\nRemediation is set out in the advisory in priority order and reduces to: validate\nthe extensio"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22",
              "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-306",
              "description": "CWE-306",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-73",
              "description": "CWE-73",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-862",
              "description": "CWE-862",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:00Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/2"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/2"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/advantech-webaccess-crystalrpt-unauth-file-upload-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/Oct/2"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] Advantech WebAccess Node 9.2.3 unauthenticated CrystalRpt.aspx file upload and path traversal to code execution in w3wp.exe (9.8)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0465",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/2",
            "automated": true,
            "contentSha256": "5c8055491691e87037814c975bf7716eb7f5af66a1d419f25cf299769481a80d",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/2",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-05T17:52:23Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:00Z",
    "dateUpdated": "2026-11-02T07:30:00Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0465"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.