GCVE-1988-2026-0486

Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
Title
[0day-rubbish] Dataedo Portal 26.2.8 with Dataedo Agent 26.2.8 unrestricted scheduler job-type deserialization to Agent-host command execution (8.1)
Summary
0day Rubbish Research Team is publicly disclosing a vulnerability in Dataedo Portal 26.2.8 together with Dataedo Agent 26.2.8, the closed-source enterprise data-catalog and data-governance platform from Dataedo sp. z o.o. (Poland). Both components are in scope because the chain crosses from one to the other: the Portal discloses a database credential, and the separately installed Agent executes an injected scheduler job on its own host. In the verified shape the command ran as `nt authority\system`. Type: deserialization of untrusted data by unrestricted invocation-type resolution (CWE-502 primary, with CWE-470 an equally defensible characterisation of the same mechanism), enabled by insufficiently protected credentials (CWE-522) under a hard-coded cryptographic key (CWE-321), with incorrect authorization and missing privilege separation (CWE-863 / CWE-284) and execution with unnecessary privileges (CWE-250 / CWE-732) contributing. The entry route works exactly as designed, which is the point. `GET /api/repository/connection-string` returns the repository database connection string to a caller holding a repository-management role, encrypted with `SimpleAES` - an AES-256-CBC construction whose 32-byte key and 16-byte IV are byte-array literals in the shipped `Dataedo.Settings.dll` and are byte-identical across builds, with PKCS7 padding and every ciphertext byte encoded as a three-digit decimal group. Anyone holding a copy of the product therefore decrypts the response offline; both values are reproduced in the published proof-of-concept. `GenerateEncryptionKey()` exists at `Dataedo.Settings:116` and no call path was found that replaces the static field with its output. A full census counted the same static pair referenced from 19 assemblies. The recovered login in the tested deployments was `sa`, a sysadmin-level principal on the repository database - and that database also holds the Hangfire scheduler storage in the `[Scheduler]` schema. The sink is on the Agent side. `AgentServiceRegistration.AddScheduler` calls `AddHangfireServer` twice, once for the `default` queue with a worker count of one and once for the `priority` queue, and registers no `ITypeResolver` restriction and no invocation allowlist with either, so Hangfire's default type resolver will resolve any type name the runtime can load. `FilterInitializer` then runs `GlobalJobFilters.Clear()` and adds four filters, none of which constrains execution: `ExecutionCreatingFilter` and `RequestUpdatingFilter` are `IClientFilter` implementations, which run on the client-side job-creation path rather than on server-side execution and additionally return early unless the declaring type implements `ISchedulerTaskExecutor`; `JobCancellationFilter` is an `IApplyStateFilter` that reacts only to transitions into `DeletedState`; and `AutomaticRetry` is configured with `Attempts = 0`, which disables retries and has no bearing on authorization. After `Clear()` nothing in the chain inspects the invocation type, the declaring type, the method name or the arguments at execution time. The producer is disciplined and the consumer is not, and the consumer is the one that executes. One row into `[Scheduler].Job` plus one row into `[Scheduler].JobQueue` is therefore enough, and no gadget chain is needed because the invocation document names the sink directly: {"Type":"System.Diagnostics.Process, System.Diagnostics.Process", "Method":"Start", "ParameterTypes":"[\"System.String\",\"System.String\"]", "Arguments":"[\"cmd.exe\",\"/c <payload>\"]"} Three details are load-bearing and none of them is obvious. The `Arguments` column and the `InvocationData.Arguments` member must both carry the command, and the latter is a JSON array serialized as a string inside the outer JSON object, so a Windows path appears with doubled backslashes in the outer document and quadrupled backslashes in the inner one while the enclosing T-SQL literal doubles every single quote. `QUOTED_IDENTIFIER` must be ON because the scheduler schema uses filtered indexes. And the `JobQueue` row must name a queue the Agent actually polls, otherwise the job exists and is never fetched. Execution lands on the Agent host as the identity of the Agent process. Two shapes were observed and both are recorded because they bound the claim: `whoami` returned `<agent-host>\administrator` when the Agent was launched from a console under an interactive administrative account, and `nt authority\system` when it ran resident as a SYSTEM-privileged scheduled task, where filtered `tasklist` output for PID 4 appended to the same file showed the System process in session 0 under the Services session name, consistent with a service-context execution environment. For production the Agent is installed as a Windows service through `AddWindowsService` with an empty `ServiceConfiguration`, so the identity is whatever that service is configured with: SYSTEM is what the default service configuration yielded in the tested shape and is not a claim about every deployment, and the installer's own service-registration table was not inspected to finality, so the production service account is an inference from the host configuration call rather than an artifact-confirmed value. How confirmation works. The recorded job was assigned identifier 7 and its state progression was read directly from the storage tables: Enqueued -> Processing (with the fetching worker's own ServerId recorded) -> Succeeded, with `PerformanceDuration` of 4 milliseconds and `State.Result` equal to "Can not serialize the return value". That pair is proof of invocation rather than of bookkeeping: `Process.Start` returns a live Process object which the scheduler cannot serialize into its state column, so it records that string, and a job that had been rejected or never fetched would not have reached Succeeded at all. A marker file was written on the Agent host by the executed command. The marker path and the marker token are command-line arguments of the published tool, and neither the path nor the token from the recorded run is reproduced here, because both are artefacts of one execution on one host rather than evidence about the product. The strongest single piece of evidence in the package is an argument-provenance control. The first injection attempt wrote a placeholder token into the `[Scheduler].Job.Arguments` column while the `InvocationData` document was correct, and the Agent's run log recorded the shell complaining that the placeholder was not recognized as an internal or external command. That establishes that the executed arguments came from the database row and not from any configuration, command line or code path inside the Agent, and it identified the column mismatch in the same breath. Without it a reviewer could reasonably ask whether the observed execution was an artefact of the test rig; with it the causality is direct. What was deliberately not reproduced. The published tool issues no destructive command, creates no account, deletes no catalog data and touches no downstream data source. The static key was validated in both cryptographic directions - decrypting a production-shaped ciphertext, and building one offline that the real Agent binary subsequently accepted into its own configuration file and connected with, which confirms the key, the IV and the encoding independently of the decryption direction - but no domain-controller or domain-administrative outcome was attempted, downstream data sources were not accessed, and NetNTLMv2 capture through the outbound-SQL surface described in the adjacent group was never demonstrated end to end. Scoring. One score is published: 8.1 High, CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H. Computed from that vector with CVSS 3.1 weights: ISS = 1 - (0.44 ^ 3) = 0.914816; Impact under Scope Changed = 7.52 * 0.885816 - 3.25 * (0.870207 ^ 13) = 6.127958; Exploitability = 8.22 * 0.85 * 0.44 * 0.50 * 0.85 = 1.306569, the PR weight being 0.50 precisely because Scope is Changed; base = 1.08 * 7.434527 = 8.029289; 8.1 after the ceiling-to-tenth Roundup. A reading of this chain as zero-click and anonymous is withdrawn, and the reversal argument is printed because it is more useful than the original claim was. An earlier reading asserted that an unauthenticated attacker could switch a running Portal's repository to an attacker-controlled database and that an already-installed Agent would follow the Portal onto that repository and execute injected jobs there - an anonymous, remote path to SYSTEM. The Agent reads its repository connection string from its own configuration file, at `Dataedo.Agent.Startup/ServicesConfigurator.cs:43`, and exposes no controller and no remote-configuration endpoint of any kind, so nothing that happens to the Portal's configuration propagates to an installed Agent. The propagation leg of the claim does not exist. A second sub-claim fell with it: that a healthy, already-configured instance can be silently switched to another repository. `POST /api/repository/set` answers HTTP 409 with an explicit "already configured" message, `create-on-existing-database` surfaces `RepositoryAlreadyConfiguredException` through `lastOperation.error`, and the validator's `IsConfigured` gate was confirmed by experiment; the HTTP 202 from `connect-and-upgrade` is a fire-and-forget acknowledgement that carries no information about whether any switch happened, and the subsequent state read showed the configured repository unchanged. Every figure published here was computed from the vector printed beside it, and no score built on the withdrawn premise was carried over. AC:H carries the two conditions that remain once PR:H is granted: a Dataedo Agent must actually be attached to that repository database - the Agent is a separately installed component, and with none attached the injected row is never fetched and nothing executes - and the attacker must have a network path to the repository listener. Both held in the verified shape and neither is a property the product guarantees. PR:H because only a principal holding role action 11 or above was demonstrated to reach the disclosure, and PR:L is supported by no evidence in this package. UI:N because no victim click, page visit or administrator action on the Agent host participates. Scope is Changed, argued on component and host grounds. The vulnerable component is the Portal web application, whose authority ends at its own process, its application-pool or service identity and the set of resources its role model governs; nothing in that model extends to a second machine. The impacted component is the Dataedo Agent host - a separately installed component, running as a separate process under a separate identity on a separate machine - reached only through a third component, the repository database, whose credentials are themselves the object of the confidentiality failure. Two observations make the boundary concrete rather than merely administrative: the attacker never authenticates to the Agent at all, and the identity gained is not the Portal's identity in any shape, since the Portal runs under a web-tier identity while the outcome is a machine-level identity on a Windows host. What Scope does NOT rest on: it is not justified by the anonymity of the adjacent group below, which is scored nowhere in this vector; not by the CORS item or the signing-key item; and not by downstream data-source compromise, which is a consequence of the Agent-host identity rather than an independent scope change. The rejected reading is printed so that the difference is auditable: 6.6 Medium, CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H, where Impact = 6.42 * 0.914816 = 5.873095 and Exploitability = 8.22 * 0.85 * 0.44 * 0.27 * 0.85 = 0.705547 under the Scope-Unchanged PR weight of 0.27, summing to 6.578642. It is rejected because the execution demonstrably occurs on another host under another component's service identity, and scoring it
Severity
No CVSS data available.
CWE
Assigner
VULNARCHIVE GNA GNA-1988
GNA scorecard E 38/100 over 552 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
unknown Dataedo Portal Affected: unknown
guessed Create a notification for this product.
Credits
disclosure via Fulldisclosure
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Dataedo Portal",
          "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 Dataedo\nPortal 26.2.8 together with Dataedo Agent 26.2.8, the closed-source enterprise\ndata-catalog and data-governance platform from Dataedo sp. z o.o. (Poland).\nBoth components are in scope because the chain crosses from one to the other:\nthe Portal discloses a database credential, and the separately installed Agent\nexecutes an injected scheduler job on its own host. In the verified shape the\ncommand ran as `nt authority\\system`.\n\nType: deserialization of untrusted data by unrestricted invocation-type\nresolution (CWE-502 primary, with CWE-470 an equally defensible\ncharacterisation of the same mechanism), enabled by insufficiently protected\ncredentials (CWE-522) under a hard-coded cryptographic key (CWE-321), with\nincorrect authorization and missing privilege separation (CWE-863 / CWE-284)\nand execution with unnecessary privileges (CWE-250 / CWE-732) contributing.\n\nThe entry route works exactly as designed, which is the point. `GET\n/api/repository/connection-string` returns the repository database connection\nstring to a caller holding a repository-management role, encrypted with\n`SimpleAES` - an AES-256-CBC construction whose 32-byte key and 16-byte IV are\nbyte-array literals in the shipped `Dataedo.Settings.dll` and are\nbyte-identical across builds, with PKCS7 padding and every ciphertext byte\nencoded as a three-digit decimal group. Anyone holding a copy of the product\ntherefore decrypts the response offline; both values are reproduced in the\npublished proof-of-concept. `GenerateEncryptionKey()` exists at\n`Dataedo.Settings:116` and no call path was found that replaces the static\nfield with its output. A full census counted the same static pair referenced\nfrom 19 assemblies. The recovered login in the tested deployments was `sa`, a\nsysadmin-level principal on the repository database - and that database also\nholds the Hangfire scheduler storage in the `[Scheduler]` schema.\n\nThe sink is on the Agent side. `AgentServiceRegistration.AddScheduler` calls\n`AddHangfireServer` twice, once for the `default` queue with a worker count of\none and once for the `priority` queue, and registers no `ITypeResolver`\nrestriction and no invocation allowlist with either, so Hangfire\u0027s default type\nresolver will resolve any type name the runtime can load. `FilterInitializer`\nthen runs `GlobalJobFilters.Clear()` and adds four filters, none of which\nconstrains execution: `ExecutionCreatingFilter` and `RequestUpdatingFilter` are\n`IClientFilter` implementations, which run on the client-side job-creation path\nrather than on server-side execution and additionally return early unless the\ndeclaring type implements `ISchedulerTaskExecutor`; `JobCancellationFilter` is\nan `IApplyStateFilter` that reacts only to transitions into `DeletedState`;\nand `AutomaticRetry` is configured with `Attempts = 0`, which disables retries\nand has no bearing on authorization. After `Clear()` nothing in the chain\ninspects the invocation type, the declaring type, the method name or the\narguments at execution time. The producer is disciplined and the consumer is\nnot, and the consumer is the one that executes.\n\nOne row into `[Scheduler].Job` plus one row into `[Scheduler].JobQueue` is\ntherefore enough, and no gadget chain is needed because the invocation document\nnames the sink directly:\n\n    {\"Type\":\"System.Diagnostics.Process, System.Diagnostics.Process\",\n     \"Method\":\"Start\",\n     \"ParameterTypes\":\"[\\\"System.String\\\",\\\"System.String\\\"]\",\n     \"Arguments\":\"[\\\"cmd.exe\\\",\\\"/c \u003cpayload\u003e\\\"]\"}\n\nThree details are load-bearing and none of them is obvious. The `Arguments`\ncolumn and the `InvocationData.Arguments` member must both carry the command,\nand the latter is a JSON array serialized as a string inside the outer JSON\nobject, so a Windows path appears with doubled backslashes in the outer\ndocument and quadrupled backslashes in the inner one while the enclosing T-SQL\nliteral doubles every single quote. `QUOTED_IDENTIFIER` must be ON because the\nscheduler schema uses filtered indexes. And the `JobQueue` row must name a\nqueue the Agent actually polls, otherwise the job exists and is never fetched.\n\nExecution lands on the Agent host as the identity of the Agent process. Two\nshapes were observed and both are recorded because they bound the claim:\n`whoami` returned `\u003cagent-host\u003e\\administrator` when the Agent was launched from\na console under an interactive administrative account, and `nt authority\\system`\nwhen it ran resident as a SYSTEM-privileged scheduled task, where filtered\n`tasklist` output for PID 4 appended to the same file showed the System process\nin session 0 under the Services session name, consistent with a service-context\nexecution environment. For production the Agent is installed as a Windows\nservice through `AddWindowsService` with an empty `ServiceConfiguration`, so\nthe identity is whatever that service is configured with: SYSTEM is what the\ndefault service configuration yielded in the tested shape and is not a claim\nabout every deployment, and the installer\u0027s own service-registration table was\nnot inspected to finality, so the production service account is an inference\nfrom the host configuration call rather than an artifact-confirmed value.\n\nHow confirmation works. The recorded job was assigned identifier 7 and its\nstate progression was read directly from the storage tables: Enqueued -\u003e\nProcessing (with the fetching worker\u0027s own ServerId recorded) -\u003e Succeeded,\nwith `PerformanceDuration` of 4 milliseconds and `State.Result` equal to \"Can\nnot serialize the return value\". That pair is proof of invocation rather than\nof bookkeeping: `Process.Start` returns a live Process object which the\nscheduler cannot serialize into its state column, so it records that string,\nand a job that had been rejected or never fetched would not have reached\nSucceeded at all. A marker file was written on the Agent host by the executed\ncommand. The marker path and the marker token are command-line arguments of the\npublished tool, and neither the path nor the token from the recorded run is\nreproduced here, because both are artefacts of one execution on one host rather\nthan evidence about the product.\n\nThe strongest single piece of evidence in the package is an argument-provenance\ncontrol. The first injection attempt wrote a placeholder token into the\n`[Scheduler].Job.Arguments` column while the `InvocationData` document was\ncorrect, and the Agent\u0027s run log recorded the shell complaining that the\nplaceholder was not recognized as an internal or external command. That\nestablishes that the executed arguments came from the database row and not from\nany configuration, command line or code path inside the Agent, and it\nidentified the column mismatch in the same breath. Without it a reviewer could\nreasonably ask whether the observed execution was an artefact of the test rig;\nwith it the causality is direct.\n\nWhat was deliberately not reproduced. The published tool issues no destructive\ncommand, creates no account, deletes no catalog data and touches no downstream\ndata source. The static key was validated in both cryptographic directions -\ndecrypting a production-shaped ciphertext, and building one offline that the\nreal Agent binary subsequently accepted into its own configuration file and\nconnected with, which confirms the key, the IV and the encoding independently\nof the decryption direction - but no domain-controller or domain-administrative\noutcome was attempted, downstream data sources were not accessed, and NetNTLMv2\ncapture through the outbound-SQL surface described in the adjacent group was\nnever demonstrated end to end.\n\nScoring. One score is published: 8.1 High,\nCVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H. Computed from that vector with\nCVSS 3.1 weights: ISS = 1 - (0.44 ^ 3) = 0.914816; Impact under Scope Changed =\n7.52 * 0.885816 - 3.25 * (0.870207 ^ 13) = 6.127958; Exploitability = 8.22 *\n0.85 * 0.44 * 0.50 * 0.85 = 1.306569, the PR weight being 0.50 precisely\nbecause Scope is Changed; base = 1.08 * 7.434527 = 8.029289; 8.1 after the\nceiling-to-tenth Roundup.\n\nA reading of this chain as zero-click and anonymous is withdrawn, and the\nreversal argument is printed because it is more useful than the original claim\nwas. An earlier reading asserted that an unauthenticated attacker could switch\na running Portal\u0027s repository to an attacker-controlled database and that an\nalready-installed Agent would follow the Portal onto that repository and\nexecute injected jobs there - an anonymous, remote path to SYSTEM. The Agent\nreads its repository connection string from its own configuration file, at\n`Dataedo.Agent.Startup/ServicesConfigurator.cs:43`, and exposes no controller\nand no remote-configuration endpoint of any kind, so nothing that happens to\nthe Portal\u0027s configuration propagates to an installed Agent. The propagation\nleg of the claim does not exist. A second sub-claim fell with it: that a\nhealthy, already-configured instance can be silently switched to another\nrepository. `POST /api/repository/set` answers HTTP 409 with an explicit\n\"already configured\" message, `create-on-existing-database` surfaces\n`RepositoryAlreadyConfiguredException` through `lastOperation.error`, and the\nvalidator\u0027s `IsConfigured` gate was confirmed by experiment; the HTTP 202 from\n`connect-and-upgrade` is a fire-and-forget acknowledgement that carries no\ninformation about whether any switch happened, and the subsequent state read\nshowed the configured repository unchanged. Every figure published here was\ncomputed from the vector printed beside it, and no score built on the withdrawn\npremise was carried over.\n\nAC:H carries the two conditions that remain once PR:H is granted: a Dataedo\nAgent must actually be attached to that repository database - the Agent is a\nseparately installed component, and with none attached the injected row is\nnever fetched and nothing executes - and the attacker must have a network path\nto the repository listener. Both held in the verified shape and neither is a\nproperty the product guarantees. PR:H because only a principal holding role\naction 11 or above was demonstrated to reach the disclosure, and PR:L is\nsupported by no evidence in this package. UI:N because no victim click, page\nvisit or administrator action on the Agent host participates.\n\nScope is Changed, argued on component and host grounds. The vulnerable\ncomponent is the Portal web application, whose authority ends at its own\nprocess, its application-pool or service identity and the set of resources its\nrole model governs; nothing in that model extends to a second machine. The\nimpacted component is the Dataedo Agent host - a separately installed\ncomponent, running as a separate process under a separate identity on a\nseparate machine - reached only through a third component, the repository\ndatabase, whose credentials are themselves the object of the confidentiality\nfailure. Two observations make the boundary concrete rather than merely\nadministrative: the attacker never authenticates to the Agent at all, and the\nidentity gained is not the Portal\u0027s identity in any shape, since the Portal\nruns under a web-tier identity while the outcome is a machine-level identity on\na Windows host. What Scope does NOT rest on: it is not justified by the\nanonymity of the adjacent group below, which is scored nowhere in this vector;\nnot by the CORS item or the signing-key item; and not by downstream data-source\ncompromise, which is a consequence of the Agent-host identity rather than an\nindependent scope change.\n\nThe rejected reading is printed so that the difference is auditable: 6.6\nMedium, CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H, where Impact = 6.42 *\n0.914816 = 5.873095 and Exploitability = 8.22 * 0.85 * 0.44 * 0.27 * 0.85 =\n0.705547 under the Scope-Unchanged PR weight of 0.27, summing to 6.578642. It\nis rejected because the execution demonstrably occurs on another host under\nanother component\u0027s service identity, and scoring it "
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "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-284",
              "description": "CWE-284",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-306",
              "description": "CWE-306",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-321",
              "description": "CWE-321",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-346",
              "description": "CWE-346",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-347",
              "description": "CWE-347",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-470",
              "description": "CWE-470",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-502",
              "description": "CWE-502",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-522",
              "description": "CWE-522",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-732",
              "description": "CWE-732",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-798",
              "description": "CWE-798",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-863",
              "description": "CWE-863",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-918",
              "description": "CWE-918",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-942",
              "description": "CWE-942",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-11-02T07:30:02Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/15"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Oct/15"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/dataedo-portal-repository-connection-string-scheduler-job-agent-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/15"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "[0day-rubbish] Dataedo Portal 26.2.8 with Dataedo Agent 26.2.8 unrestricted scheduler job-type deserialization to Agent-host command execution (8.1)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0486",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/15",
            "automated": true,
            "contentSha256": "61b32dee00457032b5c9d39c5759cf1b7c38c4d7978d3de7112b0cf70de18d5a",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/15",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-10-13T02:21:33Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-11-02T07:30:02Z",
    "dateUpdated": "2026-11-02T07:30:02Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0486"
  },
  "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.