CWE-346

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@hapi/wreck"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "18.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48022"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-319",
      "CWE-346",
      "CWE-522",
      "CWE-940"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-11T13:27:05Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nWreck strips credential headers (Authorization, Cookie, Proxy-Authorization) before following a cross-origin redirect, but the origin check compares hostnames only and ignores scheme and port. As a result, credentials are forwarded intact across same-host port changes and HTTPS-to-HTTP downgrades, allowing a co-tenant on an adjacent port or a network-position attacker capable of forging a redirect to capture bearer tokens, session cookies, and proxy credentials and impersonate the victim against the upstream service. The fix replaces the hostname comparison with a full-origin comparison (scheme, host, and port), aligning the behavior with the WHATWG Fetch same-origin definition used by browsers.\n\n### Patches\nUpgrade to \u003e= 18.1.2.\n\n### Workarounds\n- Set `redirects: 0` (default) and handle redirects manually with a strict origin check.\n- Use the `beforeRedirect` hook to inspect the redirect target and abort or strip sensitive headers before the follow-on request.",
  "id": "GHSA-x426-x7cc-3fpc",
  "modified": "2026-06-11T13:27:05Z",
  "published": "2026-06-11T13:27:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hapijs/wreck/security/advisories/GHSA-x426-x7cc-3fpc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hapijs/wreck/commit/b93323b63ad3adb14d2b4019d77219182211641e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hapijs/wreck"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@hapi/wreck: Sensitive credential headers leak across cross-port and cross-scheme redirects"
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-29868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-02T16:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Zammad 5.3.x (Fixed in 5.4.0) is vulnerable to Incorrect Access Control. An authenticated attacker with agent and customer roles could perform unauthorized changes on articles where they only have customer permissions.",
  "id": "GHSA-x53p-mh39-7rgf",
  "modified": "2024-04-04T03:46:34Z",
  "published": "2023-05-02T18:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29868"
    },
    {
      "type": "WEB",
      "url": "https://zammad.com/en/advisories/zaa-2023-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-13826"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T23:16:57Z",
    "severity": "MODERATE"
  },
  "details": "Inappropriate implementation in Autofill in Google Chrome on Android prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)",
  "id": "GHSA-x645-x4fh-pph5",
  "modified": "2026-07-01T18:31:28Z",
  "published": "2026-07-01T00:34:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13826"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/513237800"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-10846"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-10T07:16:24Z",
    "severity": "HIGH"
  },
  "details": "NLnet Labs ldns 1.2.0 up to and including versions 1.9.0, when used in applications as (stub) resolver over UDP, lacks matching the query destination address and port with the response source address and port. Furthermore not the query ID, neither the question of the query is matched with that of the response. This makes applications, that use ldns for (stub) resolver functionality over UDP, vulnerable for off-path poisoning attacks. The drill tool, which is shipped with ldns, suffers from this vulnerability.",
  "id": "GHSA-x77r-8q36-8529",
  "modified": "2026-06-17T18:35:20Z",
  "published": "2026-06-10T09:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10846"
    },
    {
      "type": "WEB",
      "url": "https://www.nlnetlabs.nl/downloads/ldns/CVE-2026-10846.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/10/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/0xERR0R/blocky"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.28.0"
            },
            {
              "fixed": "0.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T20:47:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nBlocky accepts and caches forged DNS answers while `dnssec.validate: true` is enabled. The issue has two related exploit paths:\n\n1. **Basic DNSSEC validation bypass.** If an untrusted upstream returns an unsigned positive answer for a DNSSEC-signed public domain, Blocky classifies the response as `Insecure` solely because the response contains no RRSIG records. It does not first check the DS/DNSKEY chain to determine whether the queried name is below a signed delegation. The forged unsigned answer is returned and cached.\n\n2. **Validation-cache scope pollution through forged insecure proofs.** If a response contains some RRSIG material and enters RRset validation, an attacker-controlled response path can still cause Blocky to cache `ValidationResultInsecure` for the bare domain name by returning a DS response with no DS records and an unsigned NSEC/NSEC3 record in the authority section. Blocky treats the mere presence of NSEC/NSEC3 as authenticated DS absence and stores the resulting `Insecure` state without validating the parent-zone proof. That cached state is keyed only by domain name and can be reused for later responses and cache hits.\n\nBoth paths were reproduced through Blocky\u0027s real DNS listener using external UDP DNS client queries. In both reproductions, the malicious upstream was shut down before the second query; Blocky still returned the poisoned answer from its own cache.\n\n\n## DNSSEC validation Configuration\n\nThe PoCs use Blocky\u0027s documented DNSSEC configuration model. This is not a misconfiguration.\n\nBlocky\u0027s own documentation states that the basic DNSSEC configuration is:\n\n```yaml\ndnssec:\n  validate: true\n```\n\nThe documentation says this enables DNSSEC validation with default settings and built-in root trust anchors, and that Blocky will validate DNSSEC-signed domains. It also states that, when DNSSEC validation is enabled, Blocky will:\n\n- set the DNSSEC OK bit on upstream queries;\n- validate RRSIG records;\n- verify the chain of trust from the root zone to the queried domain using DNSKEY and DS records;\n- return SERVFAIL for bogus signatures;\n- protect against cache poisoning, man-in-the-middle attacks, DNS spoofing, and forged denial-of-existence.\n\nThe implementation-side defaults match this documented usage:\n\n- `config/dnssec.go` defines `DNSSEC.Validate` as the `dnssec.validate` option.\n- `config/dnssec.go` documents `TrustAnchors []string` as custom trust anchors; an empty value uses built-in IANA root trust anchors.\n- The PoCs set `cfg.DNSSEC.Validate = true` and do not override `TrustAnchors`, so they use the documented built-in root trust-anchor path.\n- The PoCs use `config.NetProtocolTcpUdp` as the upstream transport, which is one of the documented upstream protocols.\n- The cache configuration is normal Blocky behavior: `caching.maxTime \u003e= 0` enables caching, and the PoCs set a positive `maxTime` only to make cache replay observable.\n\nTherefore, the expected behavior for a signed public domain such as `cloudflare.com.` is not to accept an unsigned forged answer. A validating resolver must determine whether the name is covered by a signed delegation before treating missing signatures as `Insecure`.\n\n## Threat models and attack paths\n\n### Attack model 1: untrusted recursive upstream or upstream-path attacker\n\nThis is the direct DNSSEC threat model. DNSSEC validation is supposed to protect clients even when the recursive upstream response path is malicious, compromised, or tampered with.\n\nThe attacker can be:\n\n- a malicious recursive upstream configured in Blocky;\n- an attacker who can tamper with plaintext UDP/TCP DNS traffic between Blocky and its upstream;\n- a compromised upstream resolver;\n- a misrouted or attacker-controlled conditional upstream.\n\nAttack steps:\n\n1. The client queries Blocky for a DNSSEC-signed public name, for example `cloudflare.com. A`.\n2. The attacker-controlled upstream returns an unsigned forged positive answer, for example `cloudflare.com. 120 IN A 203.0.113.77`.\n3. Blocky observes that the response contains no RRSIG records.\n4. Blocky returns `ValidationResultInsecure` without issuing target DS or DNSKEY queries.\n5. The forged answer is returned to the client and cached.\n6. Later clients receive the cached forged answer, even if the malicious upstream is no longer reachable.\n\nThis path is demonstrated by `attachments/external-dnssec-basic-bypass/main.go`.\n\n### Attack model 2: forged insecure proof / validation-cache scope pollution\n\nThis path exercises the validator\u0027s insecure-proof and cache-scope logic. It is relevant when the response enters RRset validation and when different DNS views or response paths can seed DNSSEC state for the same domain name.\n\nThe attacker can be:\n\n- an attacker-controlled recursive upstream;\n- a network attacker who can tamper with DS/DNSKEY auxiliary queries;\n- a conditional-forwarding or split-horizon configuration that causes the final answer and DNSSEC auxiliary lookups to come from different views;\n- a malicious upstream group selected for DNSSEC auxiliary queries but not necessarily for the original user-facing answer.\n\nAttack steps:\n\n1. The client queries Blocky for `victim.signed.example. A`.\n2. The attacker returns a poisoned A RR and an unrelated decoy RRSIG. The A RRset itself has no matching RRSIG, but the response contains some RRSIG material, so Blocky enters RRset validation instead of the simple `no RRSIG` branch.\n3. Blocky attempts to determine whether `victim.signed.example.` is in a signed or unsigned zone by querying DS records.\n4. The attacker returns a DS response with no DS records and an unsigned NSEC record in the authority section.\n5. Blocky treats the mere presence of NSEC as authenticated DS absence, caches `ValidationResultInsecure` for the bare domain name, and accepts the unsigned A RRset.\n6. The poisoned answer is returned and cached.\n7. On later queries, Blocky reuses both the poisoned DNS response cache entry and the polluted validation status. The PoC confirms replay after the malicious upstream is shut down.\n\nThis path is demonstrated by `attachments/external-dnssec-cache-scope-pollution/main.go`.\n\n## Details\n\n### 1. `no RRSIG` is treated as `Insecure` before chain status is checked\n\nIn `resolver/dnssec/validator.go`, `ValidateResponse` dispatches as follows:\n\n```go\nswitch {\ncase !v.hasAnySignatures(response):\n    v.logger.Debugf(\"No RRSIG records found for %s - zone is unsigned\", question.Name)\n    result = ValidationResultInsecure\ncase len(response.Answer) \u003e 0:\n    result = v.validateAnswer(ctx, response, question)\n...\n}\n```\n\nThe bug is the assumption that a response with no RRSIG records means the zone is unsigned. That assumption is not valid for a validating resolver. The resolver must first prove that the queried name is below an insecure delegation. For a signed domain, an unsigned positive answer should be `Bogus`, not `Insecure`.\n\nThe basic bypass PoC uses `cloudflare.com.`, a public DNSSEC-signed domain. Blocky returns `NOERROR` and the forged A record while issuing zero target DS and DNSKEY queries.\n\n### 2. Cache writes happen before outer DNSSEC validation can reject or transform the response\n\n`server/server.go:526-543` constructs the resolver chain with `dnssecResolver` before `cachingResolver` and includes a comment saying DNSSEC validation happens before caching:\n\n```text\ndnssecResolver, // DNSSEC validation BEFORE caching - validates all responses before they are cached\ncachingResolver,\n...\nupstreamTree,\n```\n\nHowever, chained resolver execution is outer-to-inner. `DNSSECResolver.Resolve` first calls `r.next.Resolve`, and `CachingResolver.Resolve` writes cache entries on misses before control returns to the DNSSEC layer:\n\n- `resolver/dnssec_resolver.go:88-96`: the DNSSEC resolver calls `r.next.Resolve(ctx, request)` before `ValidateResponse`.\n- `resolver/caching_resolver.go:225-230`: on cache miss, the cache resolver calls the next resolver and then immediately calls `putInCache`.\n- `resolver/caching_resolver.go:326-341`: the cache write only checks rcode and basic cacheability; it does not bind the entry to a DNSSEC validation result.\n\nThe practical result is that the DNS response cache can store data that has not yet survived final DNSSEC validation.\n\n### 3. Validation cache is keyed only by bare domain name\n\n`resolver/dnssec/chain.go:16-31` exposes:\n\n```go\ngetCachedValidation(domain string)\nsetCachedValidation(domain string, result ValidationResult)\n```\n\n`resolver/dnssec/validator.go:638-642` reuses this cache for zone-security checks:\n\n```go\nif cached, found := v.getCachedValidation(domain); found {\n    return cached\n}\n```\n\nThe key does not include:\n\n- qclass;\n- qtype or proof purpose;\n- current client view;\n- ECS, client IP, client name, or request client ID;\n- conditional-forwarding branch;\n- effective upstream group;\n- proof source zone;\n- parent zone;\n- trust-anchor path;\n- validation policy or algorithm set.\n\nThis allows one response path or proof purpose to seed a DNSSEC status for another path.\n\n### 4. Unsigned NSEC/NSEC3 presence is treated as authenticated DS absence\n\n`resolver/dnssec/validator.go:655-667` queries DS records when an RRset has no matching RRSIG. If no DS records are extracted, it calls `handleNoDSRecords`.\n\n`resolver/dnssec/validator.go:682-690` then does:\n\n```go\nhasNSEC := len(extractNSECRecords(dsResponse.Ns)) \u003e 0\nhasNSEC3 := len(extractNSEC3Records(dsResponse.Ns)) \u003e 0\n\nif hasNSEC || hasNSEC3 {\n    result := ValidationResultInsecure\n    v.setCachedValidation(domain, result)\n    return result\n}\n```\n\nThis code does not validate the NSEC/NSEC3 RRset signature and does not validate the parent zone chain before trusting the denial proof. The comment calls this an authenticated denial of DS existence, but the code only checks for record presence.\n\n### 5. DNSSEC auxiliary queries do not preserve original request context\n\n`resolver/dnssec_resolver.go:47-52` creates the validator with `upstream` as the resolver used for DS/DNSKEY lookups. `resolver/dnssec/query.go:57-69` builds synthetic requests containing only qname/qtype and sends them to `v.upstream.Resolve`.\n\nThose synthetic requests do not preserve the original request\u0027s client IP, client names, ECS data, request client ID, or conditional-forwarding context. `resolver/upstream_tree_resolver.go:123-162` chooses upstream groups based on client metadata; missing metadata can cause DNSSEC auxiliary queries to use a different upstream view from the answer being validated.\n\nThis is a scope problem even apart from the direct basic bypass.\n\n## Reproduction\n\n### Environment\n\n- Repository: `/home/hurrison/workspace/dnssec/repos/blocky`\n- Commit: `e0ea9b3ea56e3d074569abd3010251e7c6ebd593`\n- No root privileges required.\n- No public DNS dependency; PoCs use local loopback high ports.\n- Both PoCs query Blocky\u0027s real DNS listener through UDP.\n\n### PoC 1: basic unsigned-response DNSSEC bypass\n\nRun:\n\n```sh\ncd /home/hurrison/workspace/dnssec/repos/blocky\ngo run ./exp/external-dnssec-basic-bypass\n```\n\nArtifact:\n\n```text\nreport/artifacts/basic-bypass-output.txt\n```\n\nKey output:\n\n```text\nquery 1:\n  rcode: NOERROR\n  answers: cloudflare.com. A 203.0.113.77 ttl=120\n  target A upstream queries: 1\n  target DS upstream queries: 0\n  target DNSKEY upstream queries: 0\n\nstopping malicious upstream before query 2\nquery 2:\n  rcode: NOERROR\n  answers: cloudflare.com. A 203.0.113.77 ttl=120\n  target A upstream queries: 1\n  target DS upstream queries: 0\n  target DNSKEY upstream queries: 0\n\nBASIC BYPASS CONFIRMED: Blocky accepted and cached an unsigned poisoned response without querying DS/DNSKEY for the target.\n```\n\nInterpretation:\n\n- `cloudflare.com.` is treated as if it were insecure only because the forged response contained no RRSIG records.\n- Blocky does not query DS or DNSKEY for the target before accepting the answer.\n- The second answer is served after the malicious upstream is shut down, proving cache replay.\n\n### PoC 2: forged insecure proof and validation-cache scope pollution\n\nRun:\n\n```sh\ncd /home/hurrison/workspace/dnssec/repos/blocky\ngo run ./exp/external-dnssec-cache-scope-pollution\n```\n\nArtifact:\n\n```text\nreport/artifacts/poc-output.txt\n```\n\nKey output:\n\n```text\nquery 1:\n  rcode: NOERROR\n  answers: victim.signed.example. A 203.0.113.66 ttl=120 | decoy.victim.signed.example. RRSIG type-covered=TXT ttl=120\n  victim A upstream queries: 1\n  victim DS proof queries: 1\n\nstopping malicious upstream before query 2\nquery 2:\n  rcode: NOERROR\n  answers: victim.signed.example. A 203.0.113.66 ttl=119 | decoy.victim.signed.example. RRSIG type-covered=TXT ttl=119\n  victim A upstream queries: 1\n  victim DS proof queries: 1\n\nEXP SUCCESS: poisoned data was accepted over Blocky\u0027s DNS listener and replayed on a second external query after the malicious upstream was shut down.\n```\n\nInterpretation:\n\n- The response contains an unrelated RRSIG to force the RRset-validation path.\n- The A RRset has no matching RRSIG.\n- The forged DS response contains no DS and an unsigned NSEC in authority.\n- Blocky caches `Insecure` for the domain and returns the poisoned answer.\n- The second response is served after the malicious upstream is shut down.\n\n## Expected behavior\n\nFor a DNSSEC validating resolver:\n\n- Missing RRSIGs in a positive response must not automatically imply an insecure zone.\n- The resolver must prove that the queried name is under an insecure delegation before accepting an unsigned answer.\n- If the parent chain indicates the name should be signed, an unsigned positive answer must be treated as bogus.\n- DS absence must be proven by authenticated denial of existence, not by the mere presence of NSEC/NSEC3 records.\n- DNS response cache entries must not be written before the final DNSSEC decision, or they must be bound to validation metadata that is checked on cache hit.\n- Validation cache entries must be scoped to the proof purpose, class, view, upstream group, proof source, and trust path.\n\n## Actual behavior\n\n- Unsigned positive responses are classified as `Insecure` without DS/DNSKEY chain checks.\n- `CachingResolver` writes responses before outer DNSSEC validation runs.\n- An unsigned NSEC/NSEC3 in a DS response can mark a domain as `Insecure`.\n- The `Insecure` result is cached by bare domain name.\n- Poisoned answers are replayed from Blocky\u0027s DNS cache on later external queries.\n\n## Impact\n\nThe impact is DNSSEC validation bypass and persistent DNS cache poisoning:\n\n- forged A/AAAA/CNAME/MX/TXT records can be returned for signed domains;\n- poisoned records can be replayed to later clients for the cache TTL;\n- traffic can be redirected to attacker-controlled infrastructure;\n- update systems, package mirrors, service discovery, mail routing, and TLS bootstrapping flows may be affected depending on client behavior;\n- split-horizon and conditional-forwarding deployments may suffer cross-view validation-state pollution;\n- an attacker can also induce false `Bogus` or `Indeterminate` states in related logic, causing targeted SERVFAIL or AD-bit stripping.\n\nThe basic bypass is sufficient for a malicious or intercepted recursive upstream to defeat Blocky\u0027s documented DNSSEC protection. The cache-scope pollution path shows additional design risk in deployments with multiple views, upstream groups, or conditional forwarding.\n\n## Attachments\n\n[blocky-dnssec-validation-cache-scope-pollution-attachments.zip](https://github.com/user-attachments/files/28940249/blocky-dnssec-validation-cache-scope-pollution-attachments.zip)\n\n```text\nreport/\n  blocky-dnssec-validation-cache-scope-pollution-report.md\n  attachments/\n    external-dnssec-basic-bypass/\n      main.go\n      README.md\n    external-dnssec-cache-scope-pollution/\n      main.go\n      README.md\n  artifacts/\n    basic-bypass-output.txt\n    poc-output.txt\n```\n\nAttachment descriptions:\n\n- `attachments/external-dnssec-basic-bypass/main.go`: external PoC for the direct unsigned-response DNSSEC bypass.\n- `attachments/external-dnssec-basic-bypass/README.md`: usage notes for the basic bypass PoC.\n- `attachments/external-dnssec-cache-scope-pollution/main.go`: external PoC for forged insecure proof and validation-cache scope pollution.\n- `attachments/external-dnssec-cache-scope-pollution/README.md`: usage notes for the cache-scope PoC.\n- `artifacts/basic-bypass-output.txt`: recorded output for PoC 1.\n- `artifacts/poc-output.txt`: recorded output for PoC 2.\n\n## Credit\n\n[Yuheng Zhang @ Tsinghua University](mailto:zhangyuh25@mails.tsinghua.edu.cn)\n[Jianjun Chen@ Tsinghua University](mailto:jianjun@tsinghua.edu.cn)",
  "id": "GHSA-x845-2f78-7v36",
  "modified": "2026-06-19T20:47:46Z",
  "published": "2026-06-19T20:47:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/0xERR0R/blocky/security/advisories/GHSA-x845-2f78-7v36"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/0xERR0R/blocky"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Blocky DNSSEC validation bypass and validation-cache scope pollution"
}

{
  "affected": [],
  "aliases": [
    "CVE-2018-8235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-14T12:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A security feature bypass vulnerability exists when Microsoft Edge improperly handles requests of different origins, aka \"Microsoft Edge Security Feature Bypass Vulnerability.\" This affects Microsoft Edge.",
  "id": "GHSA-x8p6-w274-2j7p",
  "modified": "2022-05-13T01:20:42Z",
  "published": "2022-05-13T01:20:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8235"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8235"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/104343"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1041097"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2017-8793"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-05T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "An issue was discovered on Accellion FTA devices before FTA_9_12_180. By sending a POST request to home/seos/courier/web/wmProgressstat.html.php with an attacker domain in the acallow parameter, the device will respond with an Access-Control-Allow-Origin header allowing the attacker to have site access with a bypass of the Same Origin Policy.",
  "id": "GHSA-x9r2-f53m-rgrx",
  "modified": "2022-05-13T01:47:43Z",
  "published": "2022-05-13T01:47:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8793"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/anonymous/32e2894fa29176f3f32cb2b2bb7c24cb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-4917"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-29T00:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect security UI in Notifications in Google Chrome on Android prior to 103.0.5060.53 allowed a remote attacker to obscure the full screen notification via a crafted HTML page. (Chromium security severity: Low)",
  "id": "GHSA-xc42-985m-4jpv",
  "modified": "2024-04-04T06:25:31Z",
  "published": "2023-07-29T00:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4917"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2022/06/stable-channel-update-for-desktop_21.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1311683"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PQKT7EGDD2P3L7S3NXEDDRCPK4NNZNWJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YKLJ3B3D5BCVWE3QNP4N7HHF26OHD567"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-29745"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-31T00:15:10Z",
    "severity": "HIGH"
  },
  "details": "An issue found in BestWeather v.7.3.1 for Android allows unauthorized apps to cause a persistent denial of service attack by manipulating the database.",
  "id": "GHSA-xfmg-vm58-58gp",
  "modified": "2024-04-04T04:24:53Z",
  "published": "2023-05-31T00:31:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29745"
    },
    {
      "type": "WEB",
      "url": "https://github.com/LianKee/SO-CVEs/blob/main/CVEs/CVE-2023-29745/CVE%20detail.md"
    },
    {
      "type": "WEB",
      "url": "https://play.google.com/store/apps/details?id=com.TheThaiger.android"
    },
    {
      "type": "WEB",
      "url": "https://play.google.com/store/apps/details?id=com.icoolme.android.weather"
    },
    {
      "type": "WEB",
      "url": "http://www.zmtqsh.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-22077"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-27T08:16:01Z",
    "severity": "MODERATE"
  },
  "details": "OPPO Wallet APP contains a trusted domain validation flaw that allows attackers to bypass protected interface access restrictions, which may lead to account token hijacking and sensitive information disclosure.",
  "id": "GHSA-xfph-rv9m-8p8r",
  "modified": "2026-04-27T09:34:38Z",
  "published": "2026-04-27T09:34:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22077"
    },
    {
      "type": "WEB",
      "url": "https://security.oppo.com/en/noticeDetail?notice_only_key=NOTICE-2048652556296790016"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:A/V:D/RE:L/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}