Microsoft Office SharePoint Information Disclosure Vulnerability

GitHub CLI (gh) is GitHub’s official command line tool. Prior to 2.97.0, gh attestation verify  builds the certificate Subject Alternative Name matcher from the --signer-repo and --signer-workflow  flag values without escaping regex metacharacters, so a user-supplied repository or workflow name is treated as a regular expression rather than a literal string. Because GitHub permits characters such as  .  in organization, repository, and workflow path names and  .  is a regex wildcard, an attacker can register a lookalike name (for example github/artifact.attestations-workflows) that satisfies a matcher intended for a different trusted signer (github/artifact-attestations-workflows), bypassing the intended Sigstore attestation verification. Exploitation requires the attacker to create a plausible lookalike repository and produce valid attestations from it, which could undermine supply chain verification for CI/CD pipelines or policy gates that pin trust to a specific signing workflow. This issue is fixed in version 2.97.0.

GitHub CLI (gh) is GitHub's official command line tool. Prior to version 2.97.0, gh auth status masked only the characters after the last underscore in certain fine-grained personal access tokens and GitHub App tokens. As a result, part of an affected token could appear in terminal or CI output that is captured or shared. Authenticated users are affected if they ran gh auth status (without the --show-token flag) with a token type whose format contains an underscore after the prefix. This includes fine-grained personal access tokens (githubpat) and GitHub App installation and user access tokens (ghs, ghu; for example, ghs<APPID><JWT>), as well as the Actions GITHUBTOKEN. Classic tokens such as gho and ghp have an underscore-free body and are not affected. This issue is fixed in version 2.97.0.

sigstore-go fails to check signature timestamps against a signing key's validity period

Out of bounds read in Chromoting in Google Chrome on on Windows prior to 153.0.8010.36 allowed a local attacker to read memory outside the sandbox via a local program. (Chromium security severity: High)

Impact Maliciously crafted base image or build can cause a Denial of Service (DoS) condition. When creating a container from this image, memory exhaustion occurs, leading to an Out Of Memory (OOM) kill of the buildkitd process.

Patches Issue is fixed in BuildKit v0.31.1+

Workarounds Use trusted build sources.

References This is BuildKit variant of containerd advisory https://github.com/containerd/containerd/security/advisories/GHSA-jpcc-p29g-p8mq

Invoking integer overflow in NewNTUnicodeString in golang.org/x/sys/windows

FFC-DH Peer Validation Uses Attacker-Supplied q

In ssh-agent in OpenSSH before 10.5, some operations can occur remotely but were intended to occur only locally, including operations that add tokens or use keys. This is caused by misinteraction between agent locking and the session-bind@openssh.com extension.

In sshd in OpenSSH before 10.5, the restrict keyword (in authorizedkeys) was supposed to be applicable to tunnel forwarding but was not.

In tar in BusyBox through 1.37.0, a TAR archive can have filenames hidden from a listing through the use of terminal escape sequences.

In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.

A vulnerability classified as problematic has been found in GNU Binutils 2.43. This affects the function bfdelfwritesectionehframe of the file bfd/elf-eh-frame.c of the component ld. The manipulation leads to memory corruption. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. This vulnerability affects the function bfdmalloc of the file libbfd.c of the component ld. The manipulation leads to memory leak. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Vim is an open source, command line text editor. From 9.2.0511 until 9.2.0844, jsondecodeitem() in src/json.c can retain a stale pointer after jsondecodestring() invokes channelfill() to refill and free the current buffer, causing the error path to read freed memory instead of reader->jsbuf + reader->jsused when an invalid JSON string spans buffers. This issue is fixed in version 9.2.0844.

Exposure of sensitive information to an unauthorized actor in Windows Win32K allows an authorized attacker to disclose information locally.

Exposure of sensitive information to an unauthorized actor in Windows Kernel allows an authorized attacker to disclose information locally.

Chromium CVE-2026-85052: Out of bounds read in CrashReporting

Chromium: CVE-2026-84331 Incorrect authorization in Actor

Chromium: CVE-2026-84328 Missing authorization in FileSystem

Chromium: CVE-2026-84355 Incorrect authorization in Navigation

Chromium: CVE-2026-84359 Information leak in Skia

ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)

Impact

When undici parses a Set-Cookie header, it accepts any SameSite attribute value that contains Strict, Lax, or None as a substring, rather than the case-insensitive exact match specified by RFC 6265. Non-spec values are silently mapped to one of the three standard tokens:

- SameSite=NoneOfYourBusiness is parsed as None, the most permissive setting. - SameSite=StrictLax is parsed as Lax, a downgrade from Strict.

Affected applications are those that consume Set-Cookie headers from server responses (for example via undici's fetch or proxy code paths) and then forward or rely on the parsed sameSite attribute. A malicious or non-compliant server can coerce the consumer's view of a cookie's SameSite policy to a weaker value, silently degrading the SameSite enforcement the cookie is supposed to provide.

This was introduced in undici 5.15.0 when the cookies feature was added.

Patches

Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.

Workarounds

After parsing a Set-Cookie header, validate that the resulting sameSite attribute is one of 'Strict', 'Lax', or 'None' (exact, case-insensitive) before forwarding or relying on it.

A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elfswapshdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with "[f]ixed for 2.46".

OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.

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

mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()

copyhugetlbpagerange() clears the uffd-wp bit of migration and hwpoison entries with hugepteclearuffdwp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pteswpuffdwp() and pteswpmkuffdwp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages.

No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADVHWPOISON on a 2MB anon hugetlb page shows:

offset before=120e00 offset after =120e02

The fallout is mostly latent: rmap walks match migration entries by folio range and removemigrationpte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlbchangeprotection() rewriting a writable migration entry via makereadablemigrationentry(swpoffset(entry)) -- propagates it.

Migration entries legitimately carry uffd-wp, so clear it with pteswpclearuffdwp(), matching copynonpresentpte() and movehugepte().

A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by makehwpoisonentry() (trytounmapone() does not preserve uffd-wp on the hwpoison path) and hugetlbchangeprotection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely.