A flaw was found in libstdc++. An integer overflow can occur when processing large inputs to the aligned operator new in the C++ library. This vulnerability could lead to an undersized memory allocation, potentially causing memory corruption or application instability.

An integer overflow triggered when processing inputs to the C++ new operator in libstdc+-v3/libsupc+/newopa.cc where sz + align could overflow with large sz or align, potentially resulting in an undersized allocation instead of throwing badalloc. Note that this only affects older gcc versions since 12.4 onwards (see pr113258) prefer posixmemalign over alignedalloc so on the RHEL front this should only affect RHEL9 and RHEL8 system gcc. The older libstdc++ (8.5.0) has a slightly different variant of that expression but has the same overflow problem.

A security vulnerability has been detected in GNU Binutils 2.47. Affected is the function elfx8664commonsectionindex of the file bfd/elf64-x86-64.c of the component ELF Section Handler. The manipulation leads to null pointer dereference. The attack needs to be performed locally. The exploit has been disclosed publicly and may be used. Upgrading to version 2.48 is able to address this issue. The identifier of the patch is 7322e9bc30cb282575a701c307851fd3d66fee68. It is suggested to upgrade the affected component.

Calling wordexp with WRDEAPPEND in the GNU C Library version 2.0 to version 2.43 can cause the interface to return invalid memory in the wewordv member, which on subsequent calls to wordfree may abort the process.

GNU libextractor before 1.15 contains a stack-based buffer overflow vulnerability in the processstaroffice function that sizes a variable-length stack array from attacker-controlled OLE2 stream data. Attackers can craft malicious StarOffice documents that allocate up to 4 MB on the stack, causing stack overflow and crashing any application extracting metadata from the document.

GNU Emacs 28.1 through 31.1 allows arbitrary code execution upon opening a file, because an untrusted value of read-symbol-shorthands affects the intern and unintern functions. This affects the default configuration; no particular user settings are required to trigger it.

GNU Emacs < 31.0.91 Heap Over-Read via PBM/PPM/PGM Image Loader

A code execution flaw was found in Emacs, affecting versions prior to 31.2. The Flymake mode using language backends other than Lisp would execute arbitrary code from the edited file while performing syntax checking. Viewing or editing untrusted files using Emacs could lead to arbitrary code execution with the privileges of the user running Emacs.

Emacs upstream reports:

Bas Alberts of the GitHub Security Lab discovered that the fix for CVE-2024-53920, an arbitrary code execution flaw in Emacs, was incomplete. Viewing or editing untrusted text files in modes other than Emacs Lisp mode can also permit arbitrary code execution. For example:

#!/usr/bin/perl # -- mode: perl; mode: flymake -- BEGIN { system("touch uhoh.txt"); }

This problem affects all Emacs versions affected by CVE-2024-53920. This means Emacs 24 and newer, and possibly also older versions.

A minimal fix, attached, is queued up for release with Emacs 31.2. We (the Emacs upstream maintainers) don't expect to backport the fix to older Emacs releases ourselves.

Source: https://www.openwall.com/lists/oss-security/2026/09/14/1

Upstream commit - emacs-31 branch: https://github.com/emacs-mirror/emacs/commit/abc802ee2eb0b1663349ddf22a461f8e54a383fb

Upstream commit - master branch: https://github.com/emacs-mirror/emacs/commit/135e6f63f08fee3d374fa1a5187bce941a2d3e3c

A local cross-user code execution vulnerability exists in GNU wget (Windows builds from eternallybored.org) due to a hardcoded configuration file path (C:\msys64) that is writable by unprivileged users, allowing for arbitrary code execution via the useaskpass directive, potentially allowing local privilege escalation.

On Thu, 20 Aug 2026 04:09:29 +0100 Sam James wrote: Eshel Yaron has shared an arbitrary code execution bug in GNU Emacs exploitable upon opening an file. It affects >= Emacs 28.1.

The reporter has a writeup at https://eshelyaron.com/posts/2026-08-06-emacs-arbitrary-code-execution-returns.html. It's from the same reporter as CVE-2024-53920 [0].

Thread on emacs-devel: https://lists.gnu.org/archive/html/emacs-devel/2026-07/msg00453.html https://lists.gnu.org/archive/html/emacs-devel/2026-08/msg00000.html

There's a workaround patch available for Emacs 31 (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-31&id=8466eb44991707d128110bdc549fad14c8e1d61e) while on master it apparently had a bigger rework (https://cgit.git.savannah.gnu.org/cgit/emacs.git/commit/?id=c1337758a6c00e22e2a685e0556068fd73fa9a54).

In Gentoo, we backported the fix [1] down to 28.2.

[0] https://www.openwall.com/lists/oss-security/2025/02/26/2 [1] https://bugs.gentoo.org/980616 CVE-2026-96269 was assigned to this issue yesterday.

-- Tomas Hoger / Red Hat Product Security

On Tue, 22 Sep 2026 15:11:54 +0000 Bas Alberts wrote: Is GitHub going to assign a CVE here? I think GitHub assignment would be ok per this part of the GitHub CNA scope definition: "vulnerabilities affecting open source projects discovered by security researchers at GitHub or Microsoft not covered by another CNA’s scope."

If GitHub is not doing assignment, Red Hat can provide it instead. If Red Hat could provide the CVE in line with the previous finding of this report batch (CVE-2026-79992) that would be greatly appreciated. CVE-2026-96442 was assigned for this issue.

-- Tomas Hoger / Red Hat Product Security

glibc2 does not properly clear the LDDEBUGOUTPUT and LDDEBUG environmental variables when a program is spawned from a setuid program, which could allow local users to overwrite files via a symlink attack.

GnuPG (gpg) 1.0.3 does not properly check all signatures of a file containing multiple documents, which allows an attacker to modify contents of all documents but the first without detection.

Format string vulnerability in cfd daemon in GNU CFEngine before 1.6.0a11 allows attackers to execute arbitrary commands via format characters in the CAUTH command.

GNU Groff uses the current working directory to find a device description file, which allows a local user to gain additional privileges by including a malicious postpro directive in the description file, which is executed when another user runs groff.

Buffer overflow in ncurses library allows local users to execute arbitrary commands via long environmental information such as TERM or TERMINFODIRS.

A time-of-check to time-of-use (TOCTOU) race condition in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to escalate privileges. When expanding $ORIGIN in DTRPATH for setuid/setgid (ATSECURE) programs, glibc validates the lexically normalized search path against the trusted directories but then opens the raw, un-normalized path. On systems where the Linux fs.protectedhardlinks sysctl is disabled, a local attacker who hard-links such a program into an attacker-controlled directory and wins a race to replace an intermediate path component with a symbolic link can direct the loader outside the trusted directory, causing it to load an attacker-controlled shared object and execute arbitrary code with the elevated privileges of the program.

Exploitation requires an installed setuid or setgid binary whose DTRPATH uses $ORIGIN followed by ".." traversal that normalizes into a trusted directory, and the ability to hard-link that binary and win the race by swapping a path component for a symbolic link. Major Linux-based OS distributions ship with fs.protectedhardlinks enabled by default and mitigate the vulnerability.

A flaw was found in tar. A remote attacker could exploit this vulnerability by crafting a malicious archive, leading to hidden file injection with fully attacker-controlled content. This bypasses pre-extraction inspection mechanisms, potentially allowing an attacker to introduce malicious files onto a system without detection.

A flaw was found in GNU tar. The --one-top-level option is intended to confine extraction under a designated directory, but hardlink targets from the archive are not confined the same way and are resolved relative to the extraction working directory (or the directory given with -C). A crafted archive can create hardlinks inside the --one-top-level directory that point to files outside it. If a suitable symbolic link already exists under the extraction working directory, hardlinking to that symlink can bypass tar's usual symlink-based path protections and allow writing outside the intended top-level directory during a single extraction. Users who rely on --one-top-level as a security boundary when extracting untrusted archives may be affected.

A TOCTOU (Time-of-Check Time-of-Use) vulnerability in GNU tar's incremental dumpdir 'X' rename handling allows a local attacker with write access to a directory being backed up to influence the restore process if the attacker has access to the system where the restore is being performed. During restoration, files or directories may be created, renamed or overwritten outside the intended extraction directory. This could lead to unauthorized file modification or, in some cases, privilege escalation. Exploitation does not require the attacker to modify or craft the archive, and standard backup and restore workflows—including extracting into a newly created directory without using the -P option do not mitigate the issue.

A stack-based buffer overflow in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to crash or corrupt the memory of setuid/setgid (ATSECURE) programs.

When such a program's DTRPATH or DTRUNPATH begins with $ORIGIN and is followed by NUL or '/' the loader both reads past the end of the path buffer and writes past the end of a stack-allocated internal buffer. The corrupted loader stack can lead to a loader crash (denial of service) and limited disclosure of process memory.

Summary: GNU tar allows malformed archives where non-data-bearing typeflags (symlink, char device, block device, FIFO) contain a non-zero size field, leading to inconsistent behavior between listing (tar -t) and extraction (tar -x). This results in stream desynchronization and enables hidden file injection. Requirements to exploit: An attacker only needs the ability to supply a crafted tar archive to a target system that performs pre-extraction inspection using tar -t (or equivalent API) and later extracts it using GNU tar. No privileges or user interaction beyond extraction are required.

Patch Available: no

Version Fixed: N/A

Impact: Hidden file injection with fully attacker-controlled content

Bypass of pre-extraction inspection mechanisms

Single-implementation inconsistency (no cross-tool pipeline required)

Attack complexity: Low (crafted archive is < 3 KB, no special privileges)

Affected typeflags: '2', '3', '4', '6' (4 of 5 non-data typeflags)

Steps to reproduce if available:

Generate a crafted archive with a non-data-bearing typeflag (e.g., chardev) and non-zero size.

List contents

tar -tf crafted.tar

→ injected file is NOT shown

Extract archive:

tar -xf crafted.tar

Observe additional file created on disk that was not present in listing output.

A TOCTOU (Time-of-Check Time-of-Use) vulnerability in GNU tar's incremental dumpdir 'X' rename handling allows a local attacker with write access to a directory being backed up to influence the restore process if the attacker has access to the system where the restore is being performed. During restoration, files or directories may be created, renamed or overwritten outside the intended extraction directory. This could lead to unauthorized file modification or, in some cases, privilege escalation. Exploitation does not require the attacker to modify or craft the archive, and standard backup and restore workflows—including extracting into a newly created directory without using the -P option do not mitigate the issue.

A flaw was found in GNU Coreutils. The sort utility's begfield() function is vulnerable to a heap buffer under-read. The program may access memory outside the allocated buffer if a user runs a crafted command using the traditional key format. A malicious input could lead to a crash or leak sensitive data.

The vulnerability occurs in pointer arithmetic when parsing an unusually large key value (UINTMAXMAX) in traditional key syntax (+POS1.C1). If a user executes a crafted command like sort +0.18446744073709551615R, pointer arithmetic may wrap around and return a pointer before the start of the allocated buffer. This flaw can lead to an out-of-bounds memory read and potentially information disclosure.

Affected Versions: GNU Coreutils versions 7.2 through the current version are affected.

The following security advisories have been published:

GLIBC-SA-2026-0022: =================== ATSECURE programs may load attacker-controlled code via $ORIGIN

A time-of-check to time-of-use (TOCTOU) race condition in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to escalate privileges. When expanding $ORIGIN in DTRPATH for setuid/setgid (ATSECURE) programs, glibc validates the lexically normalized search path against the trusted directories but then opens the raw, un-normalized path. On systems where the Linux fs.protectedhardlinks sysctl is disabled, a local attacker who hard-links such a program into an attacker-controlled directory and wins a race to replace an intermediate path component with a symbolic link can direct the loader outside the trusted directory, causing it to load an attacker-controlled shared object and execute arbitrary code with the elevated privileges of the program.

Exploitation requires an installed setuid or setgid binary whose DTRPATH uses $ORIGIN followed by ".." traversal that normalizes into a trusted directory, and the ability to hard-link that binary and win the race by swapping a path component for a symbolic link. Major Linux-based OS distributions ship with fs.protectedhardlinks enabled by default and mitigate the vulnerability.

CVE-Id: CVE-2026-86805 Public-Date: 2026-07-06 Vulnerable-Commit: 47c3cd7a74e8c089d60d603afce6d9cf661178d6 (2.13-113) Fix-Commit: ed0c137b97eb940b4b64981e84ed806d3276edd9 (2.45) Reported-by: Jann Horn <jannh () google com> CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:L - 6.3

GLIBC-SA-2026-0023: =================== ATSECURE program buffer overflow via $ORIGIN processing

A stack-based buffer overflow in the dynamic loader (ld.so) of the GNU C Library (glibc) versions 2.14 through 2.44 allows a local attacker to crash or corrupt the memory of setuid/setgid (ATSECURE) programs.

When such a program's DTRPATH or DTRUNPATH begins with $ORIGIN and is followed by NUL or '/' the loader both reads past the end of the path buffer and writes past the end of a stack-allocated internal buffer. The corrupted loader stack can lead to a loader crash (denial of service) and limited disclosure of process memory.

CVE Id: CVE-2026-95818 Public-Date: 2026-08-14 Vulnerable-Commit: 47c3cd7a74e8c089d60d603afce6d9cf661178d6 (2.13-113) Fix-Commit: ed0c137b97eb940b4b64981e84ed806d3276edd9 (2.45) Reported-by: AISLE in partnership with Red Hat CVSS: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N - 3.6

Is GitHub going to assign a CVE here? I think GitHub assignment would be ok per this part of the GitHub CNA scope definition: "vulnerabilities affecting open source projects discovered by security researchers at GitHub or Microsoft not covered by another CNA’s scope."

If GitHub is not doing assignment, Red Hat can provide it instead. If Red Hat could provide the CVE in line with the previous finding of this report batch (CVE-2026-79992) that would be greatly appreciated.

Thanks, Bas

In elisp-mode.el in GNU Emacs before 30.1, a user who chooses to invoke elisp-completion-at-point (for code completion) on untrusted Emacs Lisp source code can trigger unsafe Lisp macro expansion that allows attackers to execute arbitrary code. (This unsafe expansion also occurs if a user chooses to enable on-the-fly diagnosis that byte compiles untrusted Emacs Lisp source code.)

A weakness has been identified in GNU Binutils 2.47. This impacts the function elflinkaddobjectsymbols of the file bfd/elflink.c. Executing a manipulation can lead to null pointer dereference. The attack needs to be launched locally. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through a bug report but has not responded yet.