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-13",
      "epss": "0.0012",
      "percentile": "0.02035"
    },
    "microsoft_vex": {
      "current_release_date": "2026-09-13T01:07:02.000Z",
      "cve": "CVE-2026-89762",
      "id": "msrc_CVE-2026-89762",
      "initial_release_date": "2026-09-13T01:07:02.000Z",
      "product_status:under_investigation": "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": "1"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-89762\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-09-11T20:20:07.377\",\"lastModified\":\"2026-09-13T07:17:40.570\",\"vulnStatus\":\"Received\",\"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.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"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\",\"versions\":[{\"version\":\"c75afcd153f6147d3b094f45a1d87e5df7f4f053\",\"lessThan\":\"361488984d668235438faac28635f3632351407f\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c75afcd153f6147d3b094f45a1d87e5df7f4f053\",\"lessThan\":\"587a6a92b93ec314c583bbf747413af170d42540\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c75afcd153f6147d3b094f45a1d87e5df7f4f053\",\"lessThan\":\"580f777d6d9fd07fc034bd1aeba5c30fd48871a2\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"c75afcd153f6147d3b094f45a1d87e5df7f4f053\",\"lessThan\":\"3f4ae5fab613dca01d6a2a8210dd832e009fcf47\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"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\",\"versions\":[{\"version\":\"2.6.36\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"2.6.36\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.109\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.18.50\",\"lessThanOrEqual\":\"6.18.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.2.4\",\"lessThanOrEqual\":\"7.2.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.3-rc1\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}]},\"references\":[{\"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\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-09-13T06:52:54+00:00",
      "cve": "CVE-2026-89762",
      "id": "CVE-2026-89762",
      "initial_release_date": "2026-09-11T19:47:03.601000+00:00",
      "product_status:known_affected": "2",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: Linux kernel AppArmor: Use-After-Free vulnerability during credential replacement",
      "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-12T23:48:17Z",
      "cve": "CVE-2026-89762",
      "id": "CVE-2026-89762",
      "initial_release_date": "2026-09-12T16:22:03Z",
      "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": "3"
    }
  }
}



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.