GCVE-1988-2026-0491

Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
Title
[0day-rubbish] South River Technologies Titan MFT Server 26.0.0 first-run administrator setup chained to job post-command injection, NT AUTHORITY\SYSTEM (8.1)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability chain in South River Technologies Titan MFT Server 26.0.0.364, the NextGen generation of the commercial managed file transfer server from South River Technologies (Annapolis, Maryland, United States). The product runs as a single .NET 8 process, titanmft.exe, registered as the Windows service SrtTitanMFTServerService under LocalSystem, serves a Blazor Server administration application on 0.0.0.0:47443 over TLS, and drives transfers with EF Core over SQLite. Before anything else, the framing. This is a first-run window, which is a deployment state, and it is not an absence of authentication. The window opens when installation completes and the service starts listening, and it closes the instant the first administrator account exists. While the administration database's nxUserParams table holds zero rows, the login route renders an "Initial Admin User Setup" screen to any client that can reach the listener. Once one administrator exists, that route renders a credential form instead and this chain's account-creation half has no route whatsoever. The product has three authentication planes and the message-level one is closed; we measured it closed, in the same run, at the same time the setup screen was available. What is exposed is a state, and no configured deployment is exposed to the half that creates the account. Type: CWE-306, Missing Authentication for Critical Function, on the first-run administrator-creation path, chained with CWE-78, Improper Neutralization of Special Elements used in an OS Command, on the job post-command path. CWE-250/CWE-269 (LocalSystem execution with no privilege separation) and CWE-209/CWE-200 (unauthenticated stack-trace echo and window-state leak) are named as contributing and are deliberately not folded into the score. CWE-1188 is deliberately not used: no insecure default credential ships with this product, and implying that rotating a password closes the exposure would be false, because creating the first administrator closes it. The gate is a row count and nothing else. MxSvrParams.cs:518-520 evaluates `RunWizard = !nxUserParams.AdminUserExists() && !CreateAdminAtConsole`, and the clearest form of the same predicate is in the legacy route: if (!nxUserParams.AdminUserExists()) CreateAdminUser(li.user.NxDecryptAPI(), li.pass.NxDecryptAPI()); There is no bootstrap ticket, no CAPTCHA, no first-boot token, no localhost restriction and no channel binding. We counted zero `[Authorize]` attributes across the 1,880 decompiled files of the ServerCore assembly, so every authorisation decision in the product lives in application logic, and for the setup screen that logic is the empty-table test. Submitting the screen calls `AppState.CreateAdminUser` followed by `AppState.Login` inside the same in-process circuit and lands the anonymous client in the management console at `/SvrHome/<guid>/<guid>`. The sink is the job post-command. The field labelled `Execute After File Transfer Task` is persisted verbatim into `nxJobs.document.PostCommandText` and is executed by the transfer engine: // MxUtilSvrJobHandler.cs:970-972 trigger predicate if (P_0.IsSuccess() || Job.ExecuteCustomPostProcessOnFileTransferTaskFailure) return !string.IsNullOrWhiteSpace(Job.PostCommandText); // MxUtilSvrJobHandler.cs:979-982 call site LogMsg("Post Command: " + Job.PostCommandText); RunCustomProcessAsync(Job.PostCommandText, Job.PostWorkingDir, Job.PostTimeout) // MxUtilSvrJobHandler.cs:991 onward (a second pass over the same // decompilation records this routine at :996) if (command.TrimStart().StartsWith("cmd", OrdinalIgnoreCase)) { fileName = "cmd.exe"; arguments = "/c " + command.Substring(3).Trim(); } else { int num = command.IndexOf(' '); fileName = num > 0 ? command.Substring(0, num) : command; arguments = num > 0 ? command.Substring(num + 1) : ""; } StartInfo = new ProcessStartInfo { FileName = fileName, Arguments = arguments, WorkingDirectory = workingDir, UseShellExecute = false, ... } Four properties make this a command injection rather than a command launcher: the `cmd`-prefix special case reconstitutes full shell semantics, so redirection, chaining, percent-expansion and quoting are all live in the payload space; otherwise the value is split on its first space with no quoting discipline; `Arguments` is a string rather than a vector, so `ArgumentList` never protects the value; and there is no allow-list, no path canonicalisation, no executable-existence check, no metacharacter rejection and no server-side re-validation between the write and the process start. The only inspection of the value on the path is `IsNullOrWhiteSpace`, which answers "should I run anything" and not "is this safe". `UseShellExecute = false` with no impersonation, no restricted token, no job object and no integrity-level downgrade means the child inherits the service token, which is LocalSystem. Identity reached: `NT AUTHORITY\SYSTEM`. The proof is a marker file, 21 bytes, content `nt authority\system`, written by the injected `cmd /c whoami` child; its modification time sits 76 milliseconds after the job-completion timestamp the product itself recorded in its own job-history table for that run. That offset is the attribution evidence: at that precision the file was written by the step that followed transfer completion in that job, not by anything else on the host. How confirmation works, and what was deliberately not reproduced. The control leg repeated the entire pipeline with one variable removed: using the administrator the exploit itself had created, the same job was re-opened, its `PostCommandText` cleared (confirmed empty both in the field and in the job document), saved, and run again. The job completed - a second job-history row, Completed, successful, zero files transferred - and the marker was untouched: same byte length, same modification time to the millisecond. The two runs were 111.6 seconds apart. That single leg removes every alternative explanation for the marker that does not involve the injected field: it was not written by the transfer engine or any pipeline stage, it is not a leftover artifact from installation or from an earlier experiment, and it was not written by a scheduled task, a service restart or a background process, because the only difference between the two runs is one field's contents. The payload was chosen to prove identity and nothing else. What we deliberately did not do: no destructive action, no persistence, no lateral movement, no domain compromise, no access to any partner system, and no second command shape beyond the one successful-transfer run and its empty-command control. The pre-transfer counterpart of the same field was not executed, so its exploitability is inference from shared code shape and is not claimed. The failing-transfer-with-payload combination was not executed either; the predicate reading that makes it work at all comes from the code plus the control row's semantics, and we do not claim that combination as measured. The published advisory reproduces the identity string but not the per-run marker path or the host names from the run. Scoring. The primary published rating is 8.1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Arithmetic: ISS = 1 - (0.44)^3 = 0.914816; Impact at S:U = 6.42 x 0.914816 = 5.87311872; Exploitability = 8.22 x 0.85 x 0.44 x 0.85 x 0.85 = 2.2211673; Base = min(5.87311872 + 2.2211673, 10) = 8.09428602; Roundup = 8.1, band High. Why AC:H and therefore why 8.1 is the headline. The chain requires the target to be inside a state the attacker cannot create: an installation that has not yet completed first-time setup. The attacker can discover such targets cheaply and cannot bring the condition about, cannot extend it and cannot re-open it from the network; once the operator completes setup the first half is gone for good. CVSS 3.1 places "the attack depends on conditions beyond the attacker's control" in Attack Complexity High, and a transient deployment state that must be found rather than caused is squarely that. We also never measured a typical window duration in any environment, so claiming AC:L as the headline would silently assume the very deployment fact we declined to measure. Conditional reading, published as conditional and never as the headline: 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, Exploitability 8.22 x 0.85 x 0.77 x 0.85 x 0.85 = 3.887042775, Base 9.760161495, Roundup 9.8. It applies to one installation confirmed to be inside its first-run window, where the state condition is already satisfied and what remains is four form submissions and a menu click. Use it when triaging a specific host; use 8.1 when triaging a fleet or a vendor. The two figures may not be swapped. Rejected readings, named so the rejection is auditable. - Scope Changed: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H computes to 9.1, and the conditional under S:C would be 10.0. The argument is coherent - the host OS is governed by Windows rather than by the product's authorisation component - and we reject it, because the child is created by the service inside the service's own LocalSystem token on the service's own host, and executing as the same service identity on the same host does not change scope. Adopting Changed also puts a conditional 10.0 on the table, which invites exactly the "this product has no authentication" misreading that the framing above exists to prevent. - Sink only: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H computes to 7.2. The post-command field on its own is a documented administrator feature; an administrator reaching LocalSystem is a privilege-separation weakness rather than remote code execution, and publishing either half in isolation would misrepresent the finding. No recorded score exists to correct here, and that is worth saying explicitly because it is unusual: the material this analysis is built from carries no CVSS vector and no base score for this finding, so both readings were derived from the metric definitions and the measured facts, computed with the CVSS 3.1 base formula, and rounded up to the tenth as that formula specifies. PR:N is a property of the chain start, not of the sink in isolation: the least privileged principal that reaches the sink by the documented path is a principal that did not exist before the request. Authentication, and the negative-control evidence behind the framing. The counter-gate measurement is the load-bearing one, and its detail matters: within the same service instance, in the same pass, an unauthenticated `POST /WebApi/Process` returned 401 with an empty body while the first-run wizard was simultaneously available to that same unauthenticated client, and `POST /api/Authenticate/Login` returned 500 with an empty body because the REST administration plane is gated by `RESTEnableAdminApi`, which has no row by default and so makes the controller constructor throw. That is a counter-gate, not a post-setup result: message-level authentication was demonstrably intact and demonstrably irrelevant, because this chain never traverses it. We are also correcting a detail of our own record rather than leaving it to be inferred: no post-setup HTTP status sample was ever captured from the login route. Our post-window evidence is exactly three observations - the setup screen is no longer rendered, a credential form is rendered in its place, and the created administrator's credentials were accepted through it. We are not going to invent a 401 on that route. The setup screen itself was measured as having zero preconditions: it submitted successfully with the EULA checkbox untouched (present but non-blocking), with no ticket parameter, with no CAPTCHA element in the DOM, with no first-boot token, and from
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
unknown South River Technologies Affected: unknown
guessed Create a notification for this product.
Credits
disclosure via Fulldisclosure
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "South River Technologies",
          "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 chain in South\nRiver Technologies Titan MFT Server 26.0.0.364, the NextGen generation of the\ncommercial managed file transfer server from South River Technologies (Annapolis,\nMaryland, United States). The product runs as a single .NET 8 process,\ntitanmft.exe, registered as the Windows service SrtTitanMFTServerService under\nLocalSystem, serves a Blazor Server administration application on 0.0.0.0:47443\nover TLS, and drives transfers with EF Core over SQLite.\n\nBefore anything else, the framing. This is a first-run window, which is a\ndeployment state, and it is not an absence of authentication. The window opens\nwhen installation completes and the service starts listening, and it closes the\ninstant the first administrator account exists. While the administration\ndatabase\u0027s nxUserParams table holds zero rows, the login route renders an\n\"Initial Admin User Setup\" screen to any client that can reach the listener.\nOnce one administrator exists, that route renders a credential form instead and\nthis chain\u0027s account-creation half has no route whatsoever. The product has\nthree authentication planes and the message-level one is closed; we measured it\nclosed, in the same run, at the same time the setup screen was available. What\nis exposed is a state, and no configured deployment is exposed to the half that\ncreates the account.\n\nType: CWE-306, Missing Authentication for Critical Function, on the first-run\nadministrator-creation path, chained with CWE-78, Improper Neutralization of\nSpecial Elements used in an OS Command, on the job post-command path.\nCWE-250/CWE-269 (LocalSystem execution with no privilege separation) and\nCWE-209/CWE-200 (unauthenticated stack-trace echo and window-state leak) are\nnamed as contributing and are deliberately not folded into the score. CWE-1188\nis deliberately not used: no insecure default credential ships with this\nproduct, and implying that rotating a password closes the exposure would be\nfalse, because creating the first administrator closes it.\n\nThe gate is a row count and nothing else. MxSvrParams.cs:518-520 evaluates\n`RunWizard = !nxUserParams.AdminUserExists() \u0026\u0026 !CreateAdminAtConsole`, and the\nclearest form of the same predicate is in the legacy route:\n\n    if (!nxUserParams.AdminUserExists())\n        CreateAdminUser(li.user.NxDecryptAPI(), li.pass.NxDecryptAPI());\n\nThere is no bootstrap ticket, no CAPTCHA, no first-boot token, no localhost\nrestriction and no channel binding. We counted zero `[Authorize]` attributes\nacross the 1,880 decompiled files of the ServerCore assembly, so every\nauthorisation decision in the product lives in application logic, and for the\nsetup screen that logic is the empty-table test. Submitting the screen calls\n`AppState.CreateAdminUser` followed by `AppState.Login` inside the same\nin-process circuit and lands the anonymous client in the management console at\n`/SvrHome/\u003cguid\u003e/\u003cguid\u003e`.\n\nThe sink is the job post-command. The field labelled `Execute After File\nTransfer Task` is persisted verbatim into `nxJobs.document.PostCommandText` and\nis executed by the transfer engine:\n\n    // MxUtilSvrJobHandler.cs:970-972  trigger predicate\n    if (P_0.IsSuccess() || Job.ExecuteCustomPostProcessOnFileTransferTaskFailure)\n        return !string.IsNullOrWhiteSpace(Job.PostCommandText);\n\n    // MxUtilSvrJobHandler.cs:979-982  call site\n    LogMsg(\"Post Command: \" + Job.PostCommandText);\n    RunCustomProcessAsync(Job.PostCommandText, Job.PostWorkingDir, Job.PostTimeout)\n\n    // MxUtilSvrJobHandler.cs:991 onward (a second pass over the same\n    // decompilation records this routine at :996)\n    if (command.TrimStart().StartsWith(\"cmd\", OrdinalIgnoreCase)) {\n        fileName  = \"cmd.exe\";\n        arguments = \"/c \" + command.Substring(3).Trim();\n    } else {\n        int num = command.IndexOf(\u0027 \u0027);\n        fileName  = num \u003e 0 ? command.Substring(0, num) : command;\n        arguments = num \u003e 0 ? command.Substring(num + 1) : \"\";\n    }\n    StartInfo = new ProcessStartInfo { FileName = fileName, Arguments = arguments,\n        WorkingDirectory = workingDir, UseShellExecute = false, ... }\n\nFour properties make this a command injection rather than a command launcher:\nthe `cmd`-prefix special case reconstitutes full shell semantics, so\nredirection, chaining, percent-expansion and quoting are all live in the payload\nspace; otherwise the value is split on its first space with no quoting\ndiscipline; `Arguments` is a string rather than a vector, so `ArgumentList`\nnever protects the value; and there is no allow-list, no path canonicalisation,\nno executable-existence check, no metacharacter rejection and no server-side\nre-validation between the write and the process start. The only inspection of\nthe value on the path is `IsNullOrWhiteSpace`, which answers \"should I run\nanything\" and not \"is this safe\". `UseShellExecute = false` with no\nimpersonation, no restricted token, no job object and no integrity-level\ndowngrade means the child inherits the service token, which is LocalSystem.\n\nIdentity reached: `NT AUTHORITY\\SYSTEM`. The proof is a marker file, 21 bytes,\ncontent `nt authority\\system`, written by the injected `cmd /c whoami` child;\nits modification time sits 76 milliseconds after the job-completion timestamp\nthe product itself recorded in its own job-history table for that run. That\noffset is the attribution evidence: at that precision the file was written by\nthe step that followed transfer completion in that job, not by anything else on\nthe host.\n\nHow confirmation works, and what was deliberately not reproduced. The control\nleg repeated the entire pipeline with one variable removed: using the\nadministrator the exploit itself had created, the same job was re-opened, its\n`PostCommandText` cleared (confirmed empty both in the field and in the job\ndocument), saved, and run again. The job completed - a second job-history row,\nCompleted, successful, zero files transferred - and the marker was untouched:\nsame byte length, same modification time to the millisecond. The two runs were\n111.6 seconds apart. That single leg removes every alternative explanation for\nthe marker that does not involve the injected field: it was not written by the\ntransfer engine or any pipeline stage, it is not a leftover artifact from\ninstallation or from an earlier experiment, and it was not written by a\nscheduled task, a service restart or a background process, because the only\ndifference between the two runs is one field\u0027s contents.\n\nThe payload was chosen to prove identity and nothing else. What we deliberately\ndid not do: no destructive action, no persistence, no lateral movement, no\ndomain compromise, no access to any partner system, and no second command shape\nbeyond the one successful-transfer run and its empty-command control. The\npre-transfer counterpart of the same field was not executed, so its\nexploitability is inference from shared code shape and is not claimed. The\nfailing-transfer-with-payload combination was not executed either; the predicate\nreading that makes it work at all comes from the code plus the control row\u0027s\nsemantics, and we do not claim that combination as measured. The published\nadvisory reproduces the identity string but not the per-run marker path or the\nhost names from the run.\n\nScoring. The primary published rating is 8.1 High,\nCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Arithmetic:\nISS = 1 - (0.44)^3 = 0.914816; Impact at S:U = 6.42 x 0.914816 = 5.87311872;\nExploitability = 8.22 x 0.85 x 0.44 x 0.85 x 0.85 = 2.2211673;\nBase = min(5.87311872 + 2.2211673, 10) = 8.09428602; Roundup = 8.1, band High.\n\nWhy AC:H and therefore why 8.1 is the headline. The chain requires the target\nto be inside a state the attacker cannot create: an installation that has not\nyet completed first-time setup. The attacker can discover such targets cheaply\nand cannot bring the condition about, cannot extend it and cannot re-open it\nfrom the network; once the operator completes setup the first half is gone for\ngood. CVSS 3.1 places \"the attack depends on conditions beyond the attacker\u0027s\ncontrol\" in Attack Complexity High, and a transient deployment state that must\nbe found rather than caused is squarely that. We also never measured a typical\nwindow duration in any environment, so claiming AC:L as the headline would\nsilently assume the very deployment fact we declined to measure.\n\nConditional reading, published as conditional and never as the headline: 9.8\nCritical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, Exploitability\n8.22 x 0.85 x 0.77 x 0.85 x 0.85 = 3.887042775, Base 9.760161495, Roundup 9.8.\nIt applies to one installation confirmed to be inside its first-run window,\nwhere the state condition is already satisfied and what remains is four form\nsubmissions and a menu click. Use it when triaging a specific host; use 8.1\nwhen triaging a fleet or a vendor. The two figures may not be swapped.\n\nRejected readings, named so the rejection is auditable.\n  - Scope Changed: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H computes to 9.1,\n    and the conditional under S:C would be 10.0. The argument is coherent - the\n    host OS is governed by Windows rather than by the product\u0027s authorisation\n    component - and we reject it, because the child is created by the service\n    inside the service\u0027s own LocalSystem token on the service\u0027s own host, and\n    executing as the same service identity on the same host does not change\n    scope. Adopting Changed also puts a conditional 10.0 on the table, which\n    invites exactly the \"this product has no authentication\" misreading that the\n    framing above exists to prevent.\n  - Sink only: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H computes to 7.2. The\n    post-command field on its own is a documented administrator feature; an\n    administrator reaching LocalSystem is a privilege-separation weakness rather\n    than remote code execution, and publishing either half in isolation would\n    misrepresent the finding.\n\nNo recorded score exists to correct here, and that is worth saying explicitly\nbecause it is unusual: the material this analysis is built from carries no CVSS\nvector and no base score for this finding, so both readings were derived from\nthe metric definitions and the measured facts, computed with the CVSS 3.1 base\nformula, and rounded up to the tenth as that formula specifies. PR:N is a\nproperty of the chain start, not of the sink in isolation: the least privileged\nprincipal that reaches the sink by the documented path is a principal that did\nnot exist before the request.\n\nAuthentication, and the negative-control evidence behind the framing. The\ncounter-gate measurement is the load-bearing one, and its detail matters: within\nthe same service instance, in the same pass, an unauthenticated\n`POST /WebApi/Process` returned 401 with an empty body while the first-run\nwizard was simultaneously available to that same unauthenticated client, and\n`POST /api/Authenticate/Login` returned 500 with an empty body because the REST\nadministration plane is gated by `RESTEnableAdminApi`, which has no row by\ndefault and so makes the controller constructor throw. That is a counter-gate,\nnot a post-setup result: message-level authentication was demonstrably intact\nand demonstrably irrelevant, because this chain never traverses it. We are also\ncorrecting a detail of our own record rather than leaving it to be inferred: no\npost-setup HTTP status sample was ever captured from the login route. Our\npost-window evidence is exactly three observations - the setup screen is no\nlonger rendered, a credential form is rendered in its place, and the created\nadministrator\u0027s credentials were accepted through it. We are not going to invent\na 401 on that route.\n\nThe setup screen itself was measured as having zero preconditions: it submitted\nsuccessfully with the EULA checkbox untouched (present but non-blocking), with no\nticket parameter, with no CAPTCHA element in the DOM, with no first-boot token,\nand from "
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-1188",
              "description": "CWE-1188",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-200",
              "description": "CWE-200",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-209",
              "description": "CWE-209",
              "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-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/20"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/20"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/southriver-titan-mft-firstrun-admin-setup-job-command-injection"
        },
        {
          "url": "https://github.com/Exploit-Garbage/0day-Rubbish"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Oct/20"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] South River Technologies Titan MFT Server 26.0.0 first-run administrator setup chained to job post-command injection, NT AUTHORITY\\SYSTEM (8.1)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0491",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/20",
            "automated": true,
            "contentSha256": "5adb567e9098c5a90b10865c6366e56faa21d7e9b61485d41bca4075c1b69fa3",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/20",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-13T02:22:46Z"
          }
        }
      ]
    }
  },
  "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-0491"
  },
  "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.