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

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.

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.

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

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.

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.

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

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.

On Mon, 14 Sep 2026 11:47:17 +0100 Sean Whitton wrote: 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.

This fix is more aggressive than the one we have on our master branch in that it also implicitly disables the Eglot flymake backend. I think we will be able to undo that before releasing Emacs 31.2, but I wanted to get this notification out as soon as possible.

I would be grateful if someone could assign us a CVE for this issue. 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.

-- Tomas Hoger / Red Hat Product Security

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

The following security advisories have been published:

GLIBC-SA-2026-0021: =================== Assertion failure in the DNS stub resolver with a long search domain

Initializing the DNS stub resolver from an /etc/resolv.conf file, or a LOCALDOMAIN environment variable, whose search list contains a domain of roughly 200 characters or more in the GNU C Library version 2.26 to 2.44 results in an assertion failure which aborts the process.

The resolver truncates the search list when copying it into the fixed-size res.defdname buffer, then asserts that the copy is consistent with the full configuration. The consistency check compared against the wrong size and did not handle a first entry that does not fit, so a correctly truncated list failed the assertion. Any process that resolves names through the library is affected, including long-running processes that reload /etc/resolv.conf on the next query after it changes. Search domains are commonly written to /etc/resolv.conf from data received over DHCP or from a VPN server, so an attacker on the local network may be able to trigger this without privileges on the target system, subject to validation by the network configuration software.

CVE-Id: CVE-2026-8674 Public-Date: 2023-11-07 Vulnerable-Commit: 3f853f22c87f0b671c0366eb290919719fa56c0e (2.26) Fix-Commit: 506ea57086bfb9ce3daff1c14246a1cb532aba0a (2.45) Reported-by: Joshua Rogers - joshua () joshua hu CVSS: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.3

Assertion failure in the DNS stub resolver with a long search domain

Hello oss-security,

A stack-based buffer overflow vulnerability was identified in GNU libextractor's OLE2 plugin for versions prior to 1.15. The vulnerability has been assigned CVE-2026-91752.

Description: 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 (Denial of Service). In multi-threaded contexts using EXTRACTOROPTIONINPROCESS, the overflow bypasses -fstack-clash-protection by overflowing into adjacent thread stack frames, allowing for arbitrary Code Execution.

Affected Versions: libextractor >= 0, < 1.15

Fix: The issue is patched in GNU libextractor version 1.15.

References: CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-91752 VulnCheck Advisory: https://www.vulncheck.com/advisories/gnu-libextractor-before-1.15-stack-overflow-via-ole2 PoC & Technical Details: https://github.com/Haitam-lazaar/libextractor-ole2-rce Upstream Patches: - https://git.gnunet.org/gnunet/libextractor/commit/04004eb19033e093938138b09befdf31e71e8522.html - https://git.gnunet.org/gnunet/libextractor/commit/2781c7e9095f4ddaff4f535d69342f3903b18422.html GNU libextractor: https://www.gnu.org/software/libextractor/

Regards, Haitam Lazaar

Hi Werner,

On Wed, Sep 16, 2026 at 11:10 AM Werner Koch <wk () gnupg org> wrote: On Wed, 16 Sep 2026 02:27, Sam James said: Werner Koch <wk () gnupg org> writes: Hi! Thank you Werner! On Mon, 14 Sep 2026 21:28, Clemens Lang said: (1) A RCE in gpgsm 2.4.9 when invoked as gpgsm --debug all --import bad.cert, with the bad.cert file at [1]. This is apparently a 0-day, Actually in all versions > 2.2 if you use --debug x509. The result is that you get garbled output on stderr. Using the certificates from their Git repo we have not been able to get more than a segv. That is obvious because the DER is used as printf format string. How it is possible to get a an RCE is not clear to me - at least not with the sample certificate. We need a real reproducers. Maybe the presentation used a custom build. It uses libgcrypt 1.12.4 which is not yet used in any binary we released.

This is the fix:

if (DBGX509) - logdebug(skider, skiderlen, "ski is:"); + logprinthex (skider, skiderlen, "ski is:");

We did not used -Wformat-nonliteral which would have caught it due to gcc problems and distros requiring -Werror. You should feel free these days to use whatever -W you want/need to. No distros should be using -Werror without at least being willing to Yes, sure. But 2003 was a different time and that part of the code was simply forgotten: So... why not delete it? Unmaintained code is a liability (and, categorically, forgotten about code is not being maintained).

A vulnerability was detected in GNU Binutils 2.47. Affected by this vulnerability is the function elfx86allocatedynrelocs of the file bfd/elfxx-x86.c of the component Dynamic Relocation Allocation. The manipulation results in null pointer dereference. The attack requires a local approach. The exploit is now public and may be used. Upgrading to version 2.48 addresses this issue. The patch is identified as d1268210b6f6/471130b39c0/283d3198bed/0a84e560216/a692a633d40. Upgrading the affected component is recommended.

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.

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.

A security flaw has been discovered in GNU Binutils 2.47. This affects the function bfdelfehframesectionoffset of the file bfd/elf-eh-frame.c of the component Eh Frame Handler. Performing a manipulation results in null pointer dereference. The attack must be initiated from a local position. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through a bug report but has not responded yet.

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.

A vulnerability was detected in GNU Binutils 2.47. The affected element is the function bfdelfstrtabdelref of the file bfd/elf-strtab.c of the component ELF String Table. The manipulation results in memory corruption. The attack requires a local approach. The exploit is now public and may be used. The project was informed of the problem early through a bug report but has not responded yet.

A security vulnerability has been detected in GNU Binutils 2.47. Impacted is the function bfdwritemergedsection of the file bfd/merge.c of the component Section Merge. The manipulation leads to null pointer dereference. The attack needs to be performed locally. The exploit has been disclosed publicly and may be used. The project was informed of the problem early through a bug report but has not responded yet.

A weakness has been identified in GNU Binutils 2.47. This issue affects the function bfdelfsetgroupcontents of the file bfd/elf.c of the component SHTGROUP Section Handler. 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.

A security flaw has been discovered in GNU Binutils 2.47. This vulnerability affects the function elforphancompatible of the file ld/ldelf.c of the component ELF Orphan Section Handler. Performing a manipulation results in null pointer dereference. The attack must be initiated from a local position. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through a bug report but has not responded yet.

The following security advisories have been published:

GLIBC-SA-2026-0017: =================== Buffer overflow in strfmon and strfmonl right-justification padding

Calling strfmon and strfmonl in the GNU C Library version 2.38 to 2.44 can write past the end of the caller-supplied output buffer when a conversion uses right-justified width padding.

Exploitation requires an application code path that calls strfmon or strfmonl with right-justified width padding into a destination buffer that is large enough for the padding to succeed but too small for the internal memmove call. The field width or format may be attacker-influenced or a fixed susceptible pattern in the caller.

At the time of publication, no network-facing application impact is known.

CVE-Id: CVE-2026-19499 CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:H - 7.7 Public-Date: 2026-08-11 Vulnerable-Commit: e88b9f0e5cc50cab57a299dc7efe1a4eb385161d (2.38) Fix-Commit: b090cf226ff65b913e41536f1f573f500855615c (2.45) Reported-by: AISLE in partnership with Red Hat

GLIBC-SA-2026-0018: =================== Stack-based out-of-bounds write in tdelete during tree rebalancing

Calling tdelete on a sufficiently deep tree in the GNU C Library version 2.1 to 2.44 may write one pointer past the end of an alloca-allocated array on the stack, which may crash the application.

The tdelete implementation keeps an explicit stack of parent nodes for rebalancing, which is grown as needed while descending the tree. Two rebalancing branches push an additional entry without checking the capacity, and write past the array when the stack is exactly full. Triggering this requires a node at a depth of exactly 40 (or 40 plus a multiple of 20), which implies a tree with at least a million nodes, so an attacker must drive a large number of insertions and deletions through an application that uses tsearch and tdelete. The written value is a pointer into a tree node and is not directly attacker controlled. No affected application in common distributions has been identified.

CVE-Id: CVE-2026-19542 Public-Date: 2026-08-11 Vulnerable-Commit: 993b3242cdc37152fbbc7fbd5ce22b2734b04b23 (1.93-194) Fix-Commit: e2789c46e3bfdcd67a82bea9946b315c179e83d3 (2.45) Fix-Commit: d6ff274313d79feb864cc10eb775b91c817a67e9 (2.44-26) Fix-Commit: 0afa34adb0fd9d756d1fe745064272e9b9aadbdc (2.43-51) Fix-Commit: 2ea357280d82dab462851419a2338d940516a37e (2.42-85) Fix-Commit: 9318c2571576017d280a31b7b9ab576c9b696b1a (2.41-154) Reported-by: AISLE in partnership with Red Hat CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L - 5.6

GLIBC-SA-2026-0019: =================== SHIFTJISX0213 decoding may hang on crafted input

Converting crafted SHIFTJISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang.

Some SHIFTJISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the SHIFTJISX0213 character set is affected, which is not commonly used. The related defect in the EUCJISX0213 converter is tracked separately as CVE-2026-80489.

CVE-Id: CVE-2026-77117 Public-Date: 2026-08-21 Vulnerable-Commit: 93a568aaba1d3da3497102dfe1eeb81070a24c1c (2.2.4-823) Fix-Commit: 68d94bbe50b7577d48998107d632ef3a0df050e3 (2.45) Fix-Commit: 6f9b2bfa500bf5d1cff5d990adfff4b71298dadd (2.44-30) Fix-Commit: 138c43f0180945b014e284a87b332d4d8237f537 (2.43-55) Fix-Commit: 67db60ee152d221782d2ae915268871d3e06a007 (2.42-88) Fix-Commit: e43e46f94398b3de446fec11da1e7633ea5202ec (2.41-157) CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.9 Reported-by: AISLE in partnership with Red Hat

GLIBC-SA-2026-0020: =================== EUCJISX0213 decoding may hang on crafted input

Converting crafted EUCJISX0213 input to UCS-4 or the internal wide character encoding, for example with iconv, in the GNU C Library version 2.3 to 2.44 may result in the converter making no progress, causing the calling application to hang.

Some EUCJISX0213 sequences decode to two code points. If the output buffer has room for only the first one, the converter stores the second in the conversion state and returns E2BIG, but it never clears that pending character after emitting it on the next call. The converter then keeps emitting the pending character without consuming further input, so an application that retries the conversion loops forever. The input must be attacker controlled and the application must convert it with an output buffer small enough to split the two code points. Only the EUCJISX0213 character set is affected, which is not commonly used. The related defect in SHIFTJISX0213 converter is tracked separately as CVE-2026-77117.

CVE-Id: CVE-2026-80489 Public-Date: 2026-08-26 Vulnerable-Commit: 93a568aaba1d3da3497102dfe1eeb81070a24c1c (2.2.4-823) Fix-Commit: 4dafa087ff5fe7df45bd37dc727e988da6b8c935 (2.45) Fix-Commit: cb61572ea3f773e1e1978f6c412cc36a30acdb0c (2.44-31) Fix-Commit: 3ad1bbd8f94a207efb108a38d434695eab8a1831 (2.43-56) Fix-Commit: 87c2795cf6a7584e351036ab43e74b03ccc54a83 (2.42-89) Fix-Commit: ec116a0fbedcc860631e525e70b409cf295f27da (2.41-158) CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H - 5.9 Reported-by: AISLE in partnership with Red Hat

A vulnerability was detected in GNU Binutils 2.47. Affected by this issue is the function bfdelfwritesectionehframe of the file bfd/elf-eh-frame.c of the component Eh Frame Section Handler. Performing a manipulation of the argument cielength/fdelength/augmentationdatasize/writeoffset results in buffer overflow. Attacking locally is a requirement. The exploit is now public and may be used. The project was informed of the problem early through a bug report but has not responded yet.

A security vulnerability has been detected in GNU Binutils 2.47. Affected by this vulnerability is the function elfx8664relocatesection of the file bfd/elf64-x86-64.c of the component ld. Such manipulation of the argument roff leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed publicly and may be used. Upgrading to version 2.48 addresses this issue. The name of the patch is 471130b39c03623ec6d78ece377ff4da3f6bfe7b. It is recommended to upgrade the affected component.

A weakness has been identified in GNU Binutils 2.47. Affected is the function bfdputl64 of the file bfd/libbfd.c of the component ld. This manipulation causes null pointer dereference. The attack requires local access. 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.