CVE-2026-97038 is a vulnerability in the Go build process where malicious packages containing ".syso" files or cgo linker inputs can inject arbitrary linker flags or execute code at link time. This occurs because linker input files were passed to the external linker without proper validation, allowing execution of disguised linker scripts or injection of unallowlisted linker flags. The Go command now enforces validation to prevent these attacks.
A vulnerability in the Go compiler's handling of cgo linker flags could allow arbitrary code execution at link time. This occurs when malicious packages pass specially crafted linker script files via "#cgo LDFLAGS". The issue involves improper handling of split "-Wl," flags that consume a following argument, which could be interpreted as positional input files or linker scripts by the host linker, particularly GNU ld.bfd. The Go command now enforces stricter validation by requiring "-Wl," prefixes on certain flags, verifying that flags do not reference linker script files, and disallowing specific problematic flags.
A vulnerability in the Go toolchain allows a crafted ".syso" file to bypass cgo flag validation and inject arbitrary linker flags during linking. This occurs because the linker incorrectly parses certain ".syso" files as Go compiler objects, enabling untrusted cgo metadata directives to be passed to the external linker without validation. Additionally, long ".syso" filenames losing their extension and unrecognized formats forced external linking in pure-Go builds. The linker has been updated to reject unrecognized ".syso" files and preserve the ".syso" suffix when truncating archive member names.
A vulnerability in GCC's handling of cgo packages allows arbitrary command execution at link time via untrusted GCC spec files. This occurs when linking with certain flags (-fopenmp, -fopenacc, or -fsanitize=) that cause GCC to evaluate and include spec files from directories that may be untrusted. The Go toolchain now rejects directories containing such spec files and disallows certain flag prefixes to mitigate this risk.
A vulnerability exists in the use of Clang or GCC compilers when building malicious Go packages that use cgo. Malicious packages can exploit certain compiler and linker flags (-gen-* and -gnat*) in #cgo directives to cause unexpected code execution during build or write files to arbitrary directories. These flags were previously allowed due to wildcard matching in the allowlists, enabling attackers to write compilation database fragments and sidecar output files outside intended locations and to desynchronize flag argument parsing, potentially passing unvalidated inputs to the linker. The problematic flags are now disallowed in #cgo compiler and linker flags to mitigate this issue.
A vulnerability in the Go compiler's handling of "//go:cgo_*" directives allowed malicious packages to inject arbitrary flags into the external linker invocation on ELF platforms. This was due to the compiler and linker not rejecting commas in certain cgo directives, enabling crafted inputs to split linker flags and potentially alter symbol exports. The issue has been addressed by rejecting commas in these directives, changing how the linker passes dynamic linker paths, and preventing symbol overwrites between import and export directives.
A vulnerability exists in the handling of "#cgo pkg-config:" directives in Go packages, where malicious packages could load untrusted pkg-config ".pc" files or inject unvalidated compiler and linker flags. This occurs due to insufficient restrictions on certain pkg-config flags and local ".pc" file paths, potentially allowing manipulation of build configurations. The Go command has been updated to disallow problematic flags and local ".pc" paths and to inspect flags for safer internal linking.
A vulnerability in the cgo build process allows malicious packages to execute arbitrary code at build time by exploiting certain compiler and linker flags in "#cgo" directives. Flags such as "--sysroot" and "-target" could be abused to redirect compiler components or execute helper tools from attacker-controlled locations. Restrictions have been applied to disallow or validate these flags to prevent exploitation.
Akaunting version 3.3.0 has a stored cross-site scripting (XSS) vulnerability in its XLSX item-import workflow. An authenticated Manager can import an item with a name containing HTML markup. When another authenticated user selects this item during document creation, the stored HTML is rendered unsafely via Vue's v-html directive, leading to execution of attacker-controlled code within the victim's Akaunting session.
A denial of service vulnerability exists in the Qt5 QtBase package due to crafted XML parsing in QXmlStreamReader (CVE-2026-16762). This issue affects Red Hat Enterprise Linux 8 and related CodeReady Linux Builder and Extended Life Cycle variants. Red Hat has issued a security advisory with an update to address this vulnerability.
The YITH WooCommerce Gift Cards WordPress plugin through 4.39.0 does not reconcile the value of a gift card it issues against the amount actually paid for it, instead crediting the new card with the item's pre-discount price, which allows customers to apply an ordinary store coupon at checkout and receive a gift card worth more than they paid.
The Security For WooCommerce WordPress plugin through 1.0.16 does not restrict access to one of its REST API routes, allowing unauthenticated users to retrieve a detailed report of the server, PHP and WordPress configuration, including installed Security For WooCommerce WordPress plugin through 1.0.16 and versions and the site administrator's email address.
The Security For WooCommerce WordPress plugin through 1.0.16 does not restrict access to one of its REST API routes, allowing unauthenticated users to retrieve the email address of every administrator on the site.
The Security For WooCommerce WordPress plugin through 1.0.16 does not check that the requester is authorised before ending a user's login sessions, allowing unauthenticated visitors to log out any user, including administrators, and to keep them logged out by repeating the request.
The Security For WooCommerce WordPress plugin through 1.0.16 does not check that the requester is authorised before regenerating the secret keys and salts in the site's configuration file, allowing unauthenticated users to log out every user and, on servers that cannot reach the WordPress.org API, corrupt the configuration file and take the whole site offline.
The Security For WooCommerce WordPress plugin through 1.0.16 does not have proper authorization checks when resetting its settings, allowing unauthenticated users to reset any section of its configuration to the defaults and so disable security features such as a custom login URL, two-factor authentication, reCAPTCHA, password policies and the firewall.
The Security For WooCommerce WordPress plugin through 1.0.16 does not check that the requester is authorised before running several of its comment cleanup actions, allowing unauthenticated users to permanently delete all comments on the site, including approved ones and WooCommerce order notes.
The Security For WooCommerce WordPress plugin through 1.0.16 does not check that the requester is authorised before running bulk Security For WooCommerce WordPress plugin through 1.0.16, and WordPress core updates, allowing unauthenticated users to force every pending update to be installed on the site.
The Security For WooCommerce WordPress plugin through 1.0.16 does not restrict access to one of its REST API routes, allowing unauthenticated users to retrieve its full settings, including configured secret keys and the hidden login URL.
The Security For WooCommerce WordPress plugin through 1.0.16 does not restrict who can request a user's current two-factor code or two-factor secret, allowing unauthenticated users to obtain them for any account and bypass the second factor on sites where its one-time password library is available.