GCVE-1988-2026-0498

Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
Title
[0day-rubbish] ProSoft Technology RLX-IFH24E v2.2.44 unsigned firmware upgrade package to root command execution and full account-database overwrite (7.2)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in the ProSoft RLX-IFH24E, version v2.2.44, the industrial wireless radio from ProSoft Technology, Inc. (United States). The appliance is a closed-source embedded device and an OEM build of the MicroHard Systems IPx21 platform on the MHX-910 board design: an Intel IXP425 XScale processor, ARM big-endian, Linux 2.4.24-uc0, with static management pages under /usr/web and 57 ARM big-endian CGI programs under /usr/lib/cgi-bin/ served by boa over HTTP and boa_ssl over HTTPS. The vendor is identified precisely here, by its legal name, its published headquarters address and its support domain, because a different and unrelated company trades under a similar name in another country, and this research concerns the United States industrial radio vendor only. ProSoft Technology's own legal pages give the entity as ProSoft Technology, Inc., 9201 Camino Media, Suite 200, Bakersfield, CA 93311, USA, and its support pages note that support addresses moved from the vendor domain to belden.com, the domain of its parent company. THE EVIDENTIAL BOUNDARY, BEFORE ANYTHING ELSE This disclosure has an unusual evidentiary shape and it is stated up front so that no reader over-reads it. No HTTP request was ever issued at this product. No physical appliance was used at any point. The chain is therefore not presented as an exploit run against a live device, and it is not one. The finding has two halves. The installer half was measured: the firmware's own /sbin/upgrade script and the other scripts in /sbin were executed byte-for-byte unmodified inside an isolated chroot sandbox built on a copy of the upgrade package's own root filesystem, with marker files and a recorded executing uid as the evidence. The upload half was inferred: it rests entirely on disassembly of the shipped ARM big-endian CGI and of the shared platform UI library, and nothing in it was observed in motion. The line between those two halves runs down the middle of the chain and is drawn explicitly wherever it appears in the published analysis. TYPE AND ROOT CAUSE Code installed and executed without an integrity or authenticity check. CWE-494 is the primary classification, with CWE-345 and CWE-347 co-equal because the only check anywhere in the path is a non-cryptographic string equality and no signature is verified at any point. CWE-434, CWE-73, CWE-250 and CWE-269 are contributing and are reported separately without raising any metric. This is explicitly not CWE-78: no command string is injected at either hop, so a command-injection remediation, filename input filtering or shell escaping would not close the chain. The shared platform helper SubProgram_Start at offset 0xbd5c splits its argument string on spaces with strtok into at most eight tokens and then calls vfork and execvp directly, so no shell is involved at all. The system upgrade package RLX-IFH24E_v2244.pkg contains four artefacts that together describe the whole path: the upload handler usr/lib/cgi-bin/tool_reprogramming.cgi, the installer /sbin/upgrade that it invokes as a root process, the factory account database /etc/passwd, and the default configuration store /etc/db1. The upload hop, recovered by disassembly. HandleSubmit at offset 0x8d1c takes the file1 part of a multipart/form-data POST to /cgi-bin/tool_reprogramming.cgi and performs this sequence, with the format string sitting at rodata offset 0x2b1c: cgiFormFileName("file1") -> the client's original filename cgiFormTempFileName -> path of the temporary body file sprintf(buf, "%s /upgrade/upgrade/%s", tempfile, origfilename) SubProgram_Start("/bin/mv", buf) ; must succeed first SubProgram_Start("/sbin/upgrade", origfilename) The original client filename is used unmodified twice: once to build the destination of the move, and once as the installer's only argument. That makes the file extension, and therefore the branch the installer takes, entirely the requester's choice. The handler applies no extension whitelist, no digest comparison and no path canonicalisation. The installer hop, executed and observed. /sbin/upgrade is a short POSIX shell script that runs with the privileges of the CGI that invoked it, which are root, and dispatches purely on ${FILE##*.}: case "$EXT" in passwd) cp /upgrade/upgrade/$FILE /etc/passwd cp /upgrade/upgrade/$FILE /etc/passwd_original ;; factory) cp /upgrade/upgrade/$FILE /etc/db1 ;; pkg) gunzip -t /upgrade/upgrade/$FILE || exit 1 tar -xf /upgrade/upgrade/$FILE -C <staging> [ "$DEVICE_PRODUCT_NAME" = "$PKG_LOCK_NAME" ] || refused echo "Match image." ./pre tar -xf extract/upgradepkg.tar -C / ./post echo "Upgrade Successful" reboot ;; esac The .pkg branch is the code-execution primitive. ./pre runs before anything else is applied, so requester-authored code executes against the pristine filesystem and can read the old state; tar -xf extract/upgradepkg.tar -C / applies an inner archive whose entry names are constrained in no way, which is an arbitrary rootfs write; ./post runs after the write, so the same requester also sees the new state; and the branch ends in an unconditional reboot, which makes the change persistent and destroys the runtime evidence. The .passwd branch is a second, independent route to the same privilege ceiling and it needs no execution at all: it copies the upload over both the live account database and the backup copy, so the device's own recovery path restores the modified database rather than the shipped one. The .factory branch is the same primitive aimed at the configuration store. The only validation the installer performs before executing package content is a string equality, and both of its operands are available to whoever supplies the package. The expected value DEVICE_PRODUCT_NAME is read from the appliance's own platform identity file /etc/MHX_CONFIG, where this firmware records PRODUCT_NAME=IPx21PROSOFT, a compile-time constant recoverable by reading the shipped firmware once. The asserted value PKG_LOCK_NAME is read from a file called lockfile inside the package being installed. A package whose identity is validated against a value carried inside that same package is not a source of assurance about that package. The gunzip -t test beside it is a gzip stream-integrity check and proves only that the file is well-formed. The check that exists was never meant to answer the authenticity question, and strengthening it would change nothing while the requester supplies both sides; what is missing from the path between an HTTP request and root execution is any authenticity step at all. WHAT WAS MEASURED A crafted .pkg carrying the correct platform string was placed in the staging directory, reproducing by hand the state the handler's /bin/mv step would have produced, and the unmodified installer was invoked on it. It printed "Match image." and then "Upgrade Successful" and exited 0. Four independent effects were observed on the sandbox filesystem: the pre and post scripts left markers proving both executed; the inner archive left a marker at the root of the filesystem, proving the unconstrained extraction; and a marker file written by the payload at runtime contained PRE-RAN-AS-UID=0. That last value is the load-bearing line, because the payload wrote it during execution rather than having it read from a configuration file, so it is the executing identity and not an inference about it. The recorded landing identity for this finding is uid=0(root). A .passwd run was performed the same way. Both /etc/passwd and /etc/passwd_original were replaced by the uploaded text: the digest recorded for the pre-seeded database before the run no longer matched afterwards, and the marker line was present in both copies. The marker line grants a uid-0 account with /bin/sh, which on this product is the difference between the factory admin shell /bin/txtUI and a general root shell available at the next interactive login. A negative control establishes that none of that came from the harness. A structurally identical package, same outer tar layout, same metadata files, same inner archive, same marker-writing scripts, with exactly one deliberate difference, LOCK_NAME=WRONGPRODUCT, was refused with "This unit doesn't support the image." and produced no markers anywhere. Three conclusions follow: the markers are produced by the install path; the observed success was conditional on that one string comparison, so the check is bypassable by supplying the documented string rather than being irrelevant; and the positive and negative runs are mutually exclusive, so the positive result cannot be explained by a sandbox in which everything appears to succeed. The run count is stated exactly because it is small. One positive .pkg run, one positive .passwd run and one negative control run, in one sandbox on one host, with each effect observed once. The runs were not repeated across multiple sandbox builds and were never performed on hardware. Four substitutions were made in the harness and none in the code under test. The firmware is ARM big-endian and the sandbox host is not, so an x86 busybox build supplied /bin/sh, tar, gunzip, mv and cp; a stub replaced the platform mhx utility; /etc/MHX_CONFIG was populated with the product identity the firmware itself ships; and /etc/passwd was pre-seeded with three factory-style entries so that a before and after comparison was possible. Two lines appearing in the transcript, "logger: not found" and "mhx: not found", are absent helpers in the sandbox PATH and are not product behaviour; they are reproduced rather than suppressed, because concealing a negative-looking line would misrepresent the run. WHAT WAS NOT MEASURED No physical appliance was used. No HTTP request was issued to the product and the uploader hop was never executed; the staging file was placed by hand. The web server was not executed and could not have been, because /bin/boa lives in the device base flash and is not contained in the system upgrade package, and it is boa that decides whether a client is allowed to fork a CGI at all. Its access control could therefore be neither proved nor disproved from the artefacts available. The CGI binaries and the firmware's own ARM helper utilities were not executed for the architecture reason. The reboot closing the .pkg branch did not happen, since the sandbox is a directory tree with no init; the path leading to it was observed up to that point. No privilege escalation is claimed, the chain starting from the administrative identity the product's own account database already grants uid 0. There is no claimed reach into the radio baseband image RLX-IFH24E_v5089.mhx, which was identified but not exercised, and no demonstrated impact on any attached control system, PLC or historian. AUTHENTICATION The finding is published as requiring administrative privilege. The package documents its own account model: admin: <DES-crypt hash>:0:0:admin:/:/bin/txtUI upgrade: <same DES-crypt hash>:500:500:ftpupgrade:/upgrade/upgrade:/bin/sh The admin account is uid 0, so the management stack is not privilege-separated and an administrative login already holds the privilege the sink needs. Its shell is /bin/txtUI, a restricted interactive interface rather than a general shell, which is a user-interface constraint and not a security boundary once arbitrary code execution is available. A second account exists with uid 500, a working /bin/sh, the same password hash, and a home directory that is precisely the upload staging path. The interface also carries a password-change page and a configurable RADIUS mode. The factory credential itself is not reproduced here; the published advisory deliberately withholds that hash. What the package establishes about th
Severity
No CVSS data available.
CWE
Assigner
VULNARCHIVE GNA GNA-1988
GNA scorecard E 38/100 over 576 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
unknown ProSoft Technology RLX-IFH24E Affected: unknown
guessed Create a notification for this product.
Credits
disclosure via Fulldisclosure
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "ProSoft Technology RLX-IFH24E",
          "vendor": "unknown",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "disclosure via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "0day Rubbish Research Team is publicly disclosing a vulnerability in the\nProSoft RLX-IFH24E, version v2.2.44, the industrial wireless radio from\nProSoft Technology, Inc. (United States). The appliance is a closed-source\nembedded device and an OEM build of the MicroHard Systems IPx21 platform on\nthe MHX-910 board design: an Intel IXP425 XScale processor, ARM\nbig-endian, Linux 2.4.24-uc0, with static management pages under /usr/web\nand 57 ARM big-endian CGI programs under /usr/lib/cgi-bin/ served by boa\nover HTTP and boa_ssl over HTTPS.\n\nThe vendor is identified precisely here, by its legal name, its published\nheadquarters address and its support domain, because a different and\nunrelated company trades under a similar name in another country, and this\nresearch concerns the United States industrial radio vendor only. ProSoft\nTechnology\u0027s own legal pages give the entity as ProSoft Technology, Inc.,\n9201 Camino Media, Suite 200, Bakersfield, CA 93311, USA, and its support\npages note that support addresses moved from the vendor domain to\nbelden.com, the domain of its parent company.\n\nTHE EVIDENTIAL BOUNDARY, BEFORE ANYTHING ELSE\n\nThis disclosure has an unusual evidentiary shape and it is stated up front\nso that no reader over-reads it. No HTTP request was ever issued at this\nproduct. No physical appliance was used at any point. The chain is therefore\nnot presented as an exploit run against a live device, and it is not one.\n\nThe finding has two halves. The installer half was measured: the firmware\u0027s\nown /sbin/upgrade script and the other scripts in /sbin were executed\nbyte-for-byte unmodified inside an isolated chroot sandbox built on a copy\nof the upgrade package\u0027s own root filesystem, with marker files and a\nrecorded executing uid as the evidence. The upload half was inferred: it\nrests entirely on disassembly of the shipped ARM big-endian CGI and of the\nshared platform UI library, and nothing in it was observed in motion. The\nline between those two halves runs down the middle of the chain and is drawn\nexplicitly wherever it appears in the published analysis.\n\nTYPE AND ROOT CAUSE\n\nCode installed and executed without an integrity or authenticity check.\nCWE-494 is the primary classification, with CWE-345 and CWE-347 co-equal\nbecause the only check anywhere in the path is a non-cryptographic string\nequality and no signature is verified at any point. CWE-434, CWE-73, CWE-250\nand CWE-269 are contributing and are reported separately without raising any\nmetric. This is explicitly not CWE-78: no command string is injected at\neither hop, so a command-injection remediation, filename input filtering or\nshell escaping would not close the chain. The shared platform helper\nSubProgram_Start at offset 0xbd5c splits its argument string on spaces with\nstrtok into at most eight tokens and then calls vfork and execvp directly,\nso no shell is involved at all.\n\nThe system upgrade package RLX-IFH24E_v2244.pkg contains four artefacts\nthat together describe the whole path: the upload handler\nusr/lib/cgi-bin/tool_reprogramming.cgi, the installer /sbin/upgrade that it\ninvokes as a root process, the factory account database /etc/passwd, and\nthe default configuration store /etc/db1.\n\nThe upload hop, recovered by disassembly. HandleSubmit at offset 0x8d1c\ntakes the file1 part of a multipart/form-data POST to\n/cgi-bin/tool_reprogramming.cgi and performs this sequence, with the format\nstring sitting at rodata offset 0x2b1c:\n\n    cgiFormFileName(\"file1\")     -\u003e the client\u0027s original filename\n    cgiFormTempFileName          -\u003e path of the temporary body file\n    sprintf(buf, \"%s /upgrade/upgrade/%s\", tempfile, origfilename)\n    SubProgram_Start(\"/bin/mv\", buf)              ; must succeed first\n    SubProgram_Start(\"/sbin/upgrade\", origfilename)\n\nThe original client filename is used unmodified twice: once to build the\ndestination of the move, and once as the installer\u0027s only argument. That\nmakes the file extension, and therefore the branch the installer takes,\nentirely the requester\u0027s choice. The handler applies no extension\nwhitelist, no digest comparison and no path canonicalisation.\n\nThe installer hop, executed and observed. /sbin/upgrade is a short POSIX\nshell script that runs with the privileges of the CGI that invoked it,\nwhich are root, and dispatches purely on ${FILE##*.}:\n\n    case \"$EXT\" in\n      passwd)  cp /upgrade/upgrade/$FILE /etc/passwd\n               cp /upgrade/upgrade/$FILE /etc/passwd_original ;;\n      factory) cp /upgrade/upgrade/$FILE /etc/db1 ;;\n      pkg)     gunzip -t /upgrade/upgrade/$FILE || exit 1\n               tar -xf /upgrade/upgrade/$FILE -C \u003cstaging\u003e\n               [ \"$DEVICE_PRODUCT_NAME\" = \"$PKG_LOCK_NAME\" ] || refused\n               echo \"Match image.\"\n               ./pre\n               tar -xf extract/upgradepkg.tar -C /\n               ./post\n               echo \"Upgrade Successful\"\n               reboot ;;\n    esac\n\nThe .pkg branch is the code-execution primitive. ./pre runs before anything\nelse is applied, so requester-authored code executes against the pristine\nfilesystem and can read the old state; tar -xf extract/upgradepkg.tar -C /\napplies an inner archive whose entry names are constrained in no way, which\nis an arbitrary rootfs write; ./post runs after the write, so the same\nrequester also sees the new state; and the branch ends in an unconditional\nreboot, which makes the change persistent and destroys the runtime\nevidence. The .passwd branch is a second, independent route to the same\nprivilege ceiling and it needs no execution at all: it copies the upload\nover both the live account database and the backup copy, so the device\u0027s own\nrecovery path restores the modified database rather than the shipped one.\nThe .factory branch is the same primitive aimed at the configuration store.\n\nThe only validation the installer performs before executing package content\nis a string equality, and both of its operands are available to whoever\nsupplies the package. The expected value DEVICE_PRODUCT_NAME is read from\nthe appliance\u0027s own platform identity file /etc/MHX_CONFIG, where this\nfirmware records PRODUCT_NAME=IPx21PROSOFT, a compile-time constant\nrecoverable by reading the shipped firmware once. The asserted value\nPKG_LOCK_NAME is read from a file called lockfile inside the package being\ninstalled. A package whose identity is validated against a value carried\ninside that same package is not a source of assurance about that package.\nThe gunzip -t test beside it is a gzip stream-integrity check and proves\nonly that the file is well-formed. The check that exists was never meant to\nanswer the authenticity question, and strengthening it would change nothing\nwhile the requester supplies both sides; what is missing from the path\nbetween an HTTP request and root execution is any authenticity step at all.\n\nWHAT WAS MEASURED\n\nA crafted .pkg carrying the correct platform string was placed in the\nstaging directory, reproducing by hand the state the handler\u0027s /bin/mv step\nwould have produced, and the unmodified installer was invoked on it. It\nprinted \"Match image.\" and then \"Upgrade Successful\" and exited 0. Four\nindependent effects were observed on the sandbox filesystem: the pre and\npost scripts left markers proving both executed; the inner archive left a\nmarker at the root of the filesystem, proving the unconstrained extraction;\nand a marker file written by the payload at runtime contained\nPRE-RAN-AS-UID=0. That last value is the load-bearing line, because the\npayload wrote it during execution rather than having it read from a\nconfiguration file, so it is the executing identity and not an inference\nabout it. The recorded landing identity for this finding is uid=0(root).\n\nA .passwd run was performed the same way. Both /etc/passwd and\n/etc/passwd_original were replaced by the uploaded text: the digest\nrecorded for the pre-seeded database before the run no longer matched\nafterwards, and the marker line was present in both copies. The marker line\ngrants a uid-0 account with /bin/sh, which on this product is the\ndifference between the factory admin shell /bin/txtUI and a general root\nshell available at the next interactive login.\n\nA negative control establishes that none of that came from the harness. A\nstructurally identical package, same outer tar layout, same metadata files,\nsame inner archive, same marker-writing scripts, with exactly one deliberate\ndifference, LOCK_NAME=WRONGPRODUCT, was refused with \"This unit doesn\u0027t\nsupport the image.\" and produced no markers anywhere. Three conclusions\nfollow: the markers are produced by the install path; the observed success\nwas conditional on that one string comparison, so the check is bypassable by\nsupplying the documented string rather than being irrelevant; and the\npositive and negative runs are mutually exclusive, so the positive result\ncannot be explained by a sandbox in which everything appears to succeed.\n\nThe run count is stated exactly because it is small. One positive .pkg run,\none positive .passwd run and one negative control run, in one sandbox on one\nhost, with each effect observed once. The runs were not repeated across\nmultiple sandbox builds and were never performed on hardware.\n\nFour substitutions were made in the harness and none in the code under test.\nThe firmware is ARM big-endian and the sandbox host is not, so an x86\nbusybox build supplied /bin/sh, tar, gunzip, mv and cp; a stub replaced the\nplatform mhx utility; /etc/MHX_CONFIG was populated with the product\nidentity the firmware itself ships; and /etc/passwd was pre-seeded with\nthree factory-style entries so that a before and after comparison was\npossible. Two lines appearing in the transcript, \"logger: not found\" and\n\"mhx: not found\", are absent helpers in the sandbox PATH and are not product\nbehaviour; they are reproduced rather than suppressed, because concealing a\nnegative-looking line would misrepresent the run.\n\nWHAT WAS NOT MEASURED\n\nNo physical appliance was used. No HTTP request was issued to the product\nand the uploader hop was never executed; the staging file was placed by\nhand. The web server was not executed and could not have been, because\n/bin/boa lives in the device base flash and is not contained in the system\nupgrade package, and it is boa that decides whether a client is allowed to\nfork a CGI at all. Its access control could therefore be neither proved nor\ndisproved from the artefacts available. The CGI binaries and the firmware\u0027s\nown ARM helper utilities were not executed for the architecture reason. The\nreboot closing the .pkg branch did not happen, since the sandbox is a\ndirectory tree with no init; the path leading to it was observed up to that\npoint. No privilege escalation is claimed, the chain starting from the\nadministrative identity the product\u0027s own account database already grants\nuid 0. There is no claimed reach into the radio baseband image\nRLX-IFH24E_v5089.mhx, which was identified but not exercised, and no\ndemonstrated impact on any attached control system, PLC or historian.\n\nAUTHENTICATION\n\nThe finding is published as requiring administrative privilege. The package\ndocuments its own account model:\n\n    admin:   \u003cDES-crypt hash\u003e:0:0:admin:/:/bin/txtUI\n    upgrade: \u003csame DES-crypt hash\u003e:500:500:ftpupgrade:/upgrade/upgrade:/bin/sh\n\nThe admin account is uid 0, so the management stack is not\nprivilege-separated and an administrative login already holds the privilege\nthe sink needs. Its shell is /bin/txtUI, a restricted interactive interface\nrather than a general shell, which is a user-interface constraint and not a\nsecurity boundary once arbitrary code execution is available. A second\naccount exists with uid 500, a working /bin/sh, the same password hash, and\na home directory that is precisely the upload staging path. The interface\nalso carries a password-change page and a configurable RADIUS mode. The\nfactory credential itself is not reproduced here; the published advisory\ndeliberately withholds that hash.\n\nWhat the package establishes about th"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-250",
              "description": "CWE-250",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-269",
              "description": "CWE-269",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-345",
              "description": "CWE-345",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-347",
              "description": "CWE-347",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-434",
              "description": "CWE-434",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-494",
              "description": "CWE-494",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-73",
              "description": "CWE-73",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-78",
              "description": "CWE-78",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:03Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/32"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/32"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/prosoft-rlx-ifh24e-unsigned-upgrade-package-root-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/32"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] ProSoft Technology RLX-IFH24E v2.2.44 unsigned firmware upgrade package to root command execution and full account-database overwrite (7.2)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0498",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/32",
            "automated": true,
            "contentSha256": "3acb301f966d5f251d5745d10e0d57410089cad24deea1811b7cf44ad01e0857",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/32",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-20T02:31:17Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:03Z",
    "dateUpdated": "2026-11-02T07:30:03Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0498"
  },
  "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
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

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.