GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2026-89762 (GCVE-0-2026-89762)

Vulnerability from cvelistv5 – Published: 2026-09-11 19:47 – Updated: 2026-09-13 06:34
VLAI
Title
apparmor: fix cred UAF caused by begin_current_label_crit_section()
Summary
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix cred UAF caused by begin_current_label_crit_section() AppArmor's begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label. The first problem with this is that it would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred->euid; ``` I don't know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF. The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in proc_pid_attr_write()), but this check can't actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds. So in approximately the following scenario, things go wrong: 1. task begins with <creds A> (as both objective and subjective creds), with refcount=2 2. task grabs an extra reference on <creds A> for overriding 3. task calls override_creds(<creds A>), which returns a pointer to the old subjective creds (<creds A>) 4. task enters AppArmor LSM hook 5. AppArmor checks that objective/subjective creds are equal 6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on <creds A> 7. task leaves AppArmor LSM hook 8. task calls revert_creds(<creds A>) 9. now task->cred is <creds A> while task->real_cred is <creds B>, but the task_struct logically holds two references to <creds B> 10. another task drops the extra reference on <creds A> that was used for overriding, refcount drops to 0 11. now task->real_cred points to freed creds At this point, any access to current_cred() will be UAF. I have a test case where I run aa-disable on a profile while a process using that profile is blocked on splice() from a FUSE passthrough file into a full pipe; after the profile update, the pipe becomes empty, splice() resumes, the credentials go out of sync, and a subsequent getuid() syscall results in a KASAN UAF splat. To fix this, instead of directly replacing creds, do it via task_work that will run at the end of the current syscall. (The point in time at which the cred replacement happens should have no correctness impact; it is just a performance optimization to avoid unnecessarily touching the refcount of the new label.) Note that AppArmor still performs direct cred replacements in the sb_pivotroot LSM hook after this change, and that direct cred replacements can still happen in VFS ->write() callbacks via proc_pid_attr_write(). There are two options for what to do with aa_dup_task_ctx(): Either explicitly reset new->label_replacement_pending after the entire aa_task_ctx has been copied, or switch to manually copying members over. I am switching to manually copying members over because that should make bugs more obvious.
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: c75afcd153f6147d3b094f45a1d87e5df7f4f053 , < 361488984d668235438faac28635f3632351407f (git)
Affected: c75afcd153f6147d3b094f45a1d87e5df7f4f053 , < 587a6a92b93ec314c583bbf747413af170d42540 (git)
Affected: c75afcd153f6147d3b094f45a1d87e5df7f4f053 , < 580f777d6d9fd07fc034bd1aeba5c30fd48871a2 (git)
Affected: c75afcd153f6147d3b094f45a1d87e5df7f4f053 , < 3f4ae5fab613dca01d6a2a8210dd832e009fcf47 (git)
guessed Create a notification for this product.
Linux Linux Affected: 2.6.36
Unaffected: 0 , < 2.6.36 (semver)
Unaffected: 6.12.109 , ≤ 6.12.* (semver)
Unaffected: 6.18.50 , ≤ 6.18.* (semver)
Unaffected: 7.2.4 , ≤ 7.2.* (semver)
Unaffected: 7.3-rc1 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "security/apparmor/include/cred.h",
            "security/apparmor/include/task.h",
            "security/apparmor/task.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "361488984d668235438faac28635f3632351407f",
              "status": "affected",
              "version": "c75afcd153f6147d3b094f45a1d87e5df7f4f053",
              "versionType": "git"
            },
            {
              "lessThan": "587a6a92b93ec314c583bbf747413af170d42540",
              "status": "affected",
              "version": "c75afcd153f6147d3b094f45a1d87e5df7f4f053",
              "versionType": "git"
            },
            {
              "lessThan": "580f777d6d9fd07fc034bd1aeba5c30fd48871a2",
              "status": "affected",
              "version": "c75afcd153f6147d3b094f45a1d87e5df7f4f053",
              "versionType": "git"
            },
            {
              "lessThan": "3f4ae5fab613dca01d6a2a8210dd832e009fcf47",
              "status": "affected",
              "version": "c75afcd153f6147d3b094f45a1d87e5df7f4f053",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "security/apparmor/include/cred.h",
            "security/apparmor/include/task.h",
            "security/apparmor/task.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "2.6.36"
            },
            {
              "lessThan": "2.6.36",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.109",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.50",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.4",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3-rc1",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.109",
                  "versionStartIncluding": "2.6.36",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.50",
                  "versionStartIncluding": "2.6.36",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2.4",
                  "versionStartIncluding": "2.6.36",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.3-rc1",
                  "versionStartIncluding": "2.6.36",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix cred UAF caused by begin_current_label_crit_section()\n\nAppArmor\u0027s begin_current_label_crit_section() is a scary function called\nfrom lots of LSM hooks (in particular VFS/socket-related ones) that checks\nif the label referenced by the current creds is marked FLAG_STALE, and if\nso, attempts to use aa_replace_current_label() to replace the creds with an\nupdated version that uses a new label.\n\nThe first problem with this is that it would directly lead to UAF of\n`struct cred` if anything in the kernel takes a pointer to the current\ncreds and accesses these past a security hook invocation that replaces\ncreds, like so:\n```\nconst struct cred *cred = current_cred();\nalloc_file_pseudo(...);\nuid_t uid = cred-\u003eeuid;\n```\nI don\u0027t know if anything in the kernel actually does this, but I think it\nis very surprising that this pattern could lead to UAF.\n\nThe second problem is that things go wrong when aa_replace_current_label()\nruns with overridden credentials. aa_replace_current_label() bails out if\n`current_cred() != current_real_cred()` (mirroring the check in\nproc_pid_attr_write()), but this check can\u0027t actually reliably detect\noverridden credentials because the overridden creds can be the same as the\nobjective creds.\n\nSo in approximately the following scenario, things go wrong:\n\n1. task begins with \u003ccreds A\u003e (as both objective and subjective creds),\n   with refcount=2\n2. task grabs an extra reference on \u003ccreds A\u003e for overriding\n3. task calls override_creds(\u003ccreds A\u003e), which returns a pointer to the old\n   subjective creds (\u003ccreds A\u003e)\n4. task enters AppArmor LSM hook\n5. AppArmor checks that objective/subjective creds are equal\n6. AppArmor replaces both cred pointers with \u003ccreds B\u003e and drops 2 refs on\n   \u003ccreds A\u003e\n7. task leaves AppArmor LSM hook\n8. task calls revert_creds(\u003ccreds A\u003e)\n9. now task-\u003ecred is \u003ccreds A\u003e while task-\u003ereal_cred is \u003ccreds B\u003e, but the\n   task_struct logically holds two references to \u003ccreds B\u003e\n10. another task drops the extra reference on \u003ccreds A\u003e that was used for\n    overriding, refcount drops to 0\n11. now task-\u003ereal_cred points to freed creds\n\nAt this point, any access to current_cred() will be UAF.\n\nI have a test case where I run aa-disable on a profile while a process\nusing that profile is blocked on splice() from a FUSE passthrough file into\na full pipe; after the profile update, the pipe becomes empty, splice()\nresumes, the credentials go out of sync, and a subsequent getuid() syscall\nresults in a KASAN UAF splat.\n\nTo fix this, instead of directly replacing creds, do it via task_work that\nwill run at the end of the current syscall. (The point in time at which the\ncred replacement happens should have no correctness impact; it is just a\nperformance optimization to avoid unnecessarily touching the refcount of\nthe new label.)\n\nNote that AppArmor still performs direct cred replacements in the\nsb_pivotroot LSM hook after this change, and that direct cred replacements\ncan still happen in VFS -\u003ewrite() callbacks via proc_pid_attr_write().\n\nThere are two options for what to do with aa_dup_task_ctx(): Either\nexplicitly reset new-\u003elabel_replacement_pending after the entire\naa_task_ctx has been copied, or switch to manually copying members over.\nI am switching to manually copying members over because that should make\nbugs more obvious."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - begin_current_label_crit_section() runs from AppArmor LSM hooks on local VFS/socket syscalls after a stale profile replace. The confirmed UAF is splice from a FUSE passthrough file under override_creds() of the same cred object; unprivileged binfmt_misc register does the same around open_exec(). This is not a network receive path.\nAC:L - The attacker controls both sides: they replace the AppArmor profile to mark the task label FLAG_STALE, then invoke a syscall that override_creds()s with that same cred object (FUSE passthrough splice into a full pipe, or binfmt_misc OPEN_FILE register). The author\u2019s sequence is attacker-driven, not a victim-dependent race.\nPR:L - Making the label stale requires AppArmor policy replace (CAP_MAC_ADMIN), but unprivileged_userns_apparmor_policy defaults to 1 so userns root can load/replace policy. The LSM hooks and same-cred override_creds sites, including unprivileged binfmt_misc (FS_USERNS_MOUNT), are reachable without init-namespace root.\nUI:N - The attacker confines their own task, replaces their own policy, and triggers the override_creds VFS path themselves; no separate victim user action is required.\nS:U - Impact is a kernel struct cred use-after-free and local privilege escalation within the same kernel security authority. It is not a VM escape, IOMMU bypass, or cross-authority sandbox break.\nC:H - This is a use-after-free of struct cred: aa_replace_current_label() drops the task\u2019s refs during override_creds(), then revert_creds() restores a dangling cred pointer. Reclaiming the cred slab yields an arbitrary kernel read. Kernel UAF scores C:H.\nI:H - The same cred UAF is a classic heap-spray primitive on struct cred, enabling arbitrary writes and control-flow hijacking / privilege escalation. Kernel UAF scores I:H.\nA:H - The author reproduced a KASAN use-after-free of current_cred() on a later getuid() after the FUSE splice sequence; dereferencing the freed cred oopses or panics the kernel."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-13T06:34:06.338Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f"
        },
        {
          "url": "https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540"
        },
        {
          "url": "https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2"
        },
        {
          "url": "https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47"
        }
      ],
      "title": "apparmor: fix cred UAF caused by begin_current_label_crit_section()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-89762",
    "datePublished": "2026-09-11T19:47:03.601Z",
    "dateReserved": "2026-09-11T19:38:34.764Z",
    "dateUpdated": "2026-09-13T06:34:06.338Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-89762",
      "date": "2026-09-17",
      "epss": "0.0012",
      "percentile": "0.02058"
    },
    "microsoft_vex": {
      "current_release_date": "2026-09-14T14:53:27.000Z",
      "cve": "CVE-2026-89762",
      "id": "msrc_CVE-2026-89762",
      "initial_release_date": "2026-09-13T01:07:02.000Z",
      "product_status:known_affected": "1",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "apparmor: fix cred UAF caused by begin_current_label_crit_section()",
      "url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-89762.json",
      "version": "2"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "security/apparmor/include/cred.h",
                  "security/apparmor/include/task.h",
                  "security/apparmor/task.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "361488984d668235438faac28635f3632351407f",
                    "status": "affected",
                    "version": "c75afcd153f6147d3b094f45a1d87e5df7f4f053",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "587a6a92b93ec314c583bbf747413af170d42540",
                    "status": "affected",
                    "version": "c75afcd153f6147d3b094f45a1d87e5df7f4f053",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "580f777d6d9fd07fc034bd1aeba5c30fd48871a2",
                    "status": "affected",
                    "version": "c75afcd153f6147d3b094f45a1d87e5df7f4f053",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "3f4ae5fab613dca01d6a2a8210dd832e009fcf47",
                    "status": "affected",
                    "version": "c75afcd153f6147d3b094f45a1d87e5df7f4f053",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "security/apparmor/include/cred.h",
                  "security/apparmor/include/task.h",
                  "security/apparmor/task.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "2.6.36"
                  },
                  {
                    "lessThan": "2.6.36",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.109",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.50",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.2.*",
                    "status": "unaffected",
                    "version": "7.2.4",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.3-rc1",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix cred UAF caused by begin_current_label_crit_section()\n\nAppArmor\u0027s begin_current_label_crit_section() is a scary function called\nfrom lots of LSM hooks (in particular VFS/socket-related ones) that checks\nif the label referenced by the current creds is marked FLAG_STALE, and if\nso, attempts to use aa_replace_current_label() to replace the creds with an\nupdated version that uses a new label.\n\nThe first problem with this is that it would directly lead to UAF of\n`struct cred` if anything in the kernel takes a pointer to the current\ncreds and accesses these past a security hook invocation that replaces\ncreds, like so:\n```\nconst struct cred *cred = current_cred();\nalloc_file_pseudo(...);\nuid_t uid = cred-\u003eeuid;\n```\nI don\u0027t know if anything in the kernel actually does this, but I think it\nis very surprising that this pattern could lead to UAF.\n\nThe second problem is that things go wrong when aa_replace_current_label()\nruns with overridden credentials. aa_replace_current_label() bails out if\n`current_cred() != current_real_cred()` (mirroring the check in\nproc_pid_attr_write()), but this check can\u0027t actually reliably detect\noverridden credentials because the overridden creds can be the same as the\nobjective creds.\n\nSo in approximately the following scenario, things go wrong:\n\n1. task begins with \u003ccreds A\u003e (as both objective and subjective creds),\n   with refcount=2\n2. task grabs an extra reference on \u003ccreds A\u003e for overriding\n3. task calls override_creds(\u003ccreds A\u003e), which returns a pointer to the old\n   subjective creds (\u003ccreds A\u003e)\n4. task enters AppArmor LSM hook\n5. AppArmor checks that objective/subjective creds are equal\n6. AppArmor replaces both cred pointers with \u003ccreds B\u003e and drops 2 refs on\n   \u003ccreds A\u003e\n7. task leaves AppArmor LSM hook\n8. task calls revert_creds(\u003ccreds A\u003e)\n9. now task-\u003ecred is \u003ccreds A\u003e while task-\u003ereal_cred is \u003ccreds B\u003e, but the\n   task_struct logically holds two references to \u003ccreds B\u003e\n10. another task drops the extra reference on \u003ccreds A\u003e that was used for\n    overriding, refcount drops to 0\n11. now task-\u003ereal_cred points to freed creds\n\nAt this point, any access to current_cred() will be UAF.\n\nI have a test case where I run aa-disable on a profile while a process\nusing that profile is blocked on splice() from a FUSE passthrough file into\na full pipe; after the profile update, the pipe becomes empty, splice()\nresumes, the credentials go out of sync, and a subsequent getuid() syscall\nresults in a KASAN UAF splat.\n\nTo fix this, instead of directly replacing creds, do it via task_work that\nwill run at the end of the current syscall. (The point in time at which the\ncred replacement happens should have no correctness impact; it is just a\nperformance optimization to avoid unnecessarily touching the refcount of\nthe new label.)\n\nNote that AppArmor still performs direct cred replacements in the\nsb_pivotroot LSM hook after this change, and that direct cred replacements\ncan still happen in VFS -\u003ewrite() callbacks via proc_pid_attr_write().\n\nThere are two options for what to do with aa_dup_task_ctx(): Either\nexplicitly reset new-\u003elabel_replacement_pending after the entire\naa_task_ctx has been copied, or switch to manually copying members over.\nI am switching to manually copying members over because that should make\nbugs more obvious."
          }
        ],
        "id": "CVE-2026-89762",
        "lastModified": "2026-09-13T07:17:40.570",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-09-11T20:20:07.377",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/361488984d668235438faac28635f3632351407f"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/3f4ae5fab613dca01d6a2a8210dd832e009fcf47"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/580f777d6d9fd07fc034bd1aeba5c30fd48871a2"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/587a6a92b93ec314c583bbf747413af170d42540"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Received"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-09-15T11:39:48+00:00",
      "cve": "CVE-2026-89762",
      "id": "CVE-2026-89762",
      "initial_release_date": "2026-09-11T00:00:00+00:00",
      "product_status:known_not_affected": "276",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: apparmor: fix cred UAF caused by begin_current_label_crit_section()",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-89762.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-09-17T16:40:12Z",
      "cve": "CVE-2026-89762",
      "id": "CVE-2026-89762",
      "initial_release_date": "2026-09-12T16:22:03Z",
      "product_status:known_affected": "353",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-89762",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-89762.json",
      "version": "5"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.