Impact

When generating an API plugin manifest from an attacker-controlled or compromised OpenAPI description, Kiota copies x-ai-capabilities.responsesemantics.oauthcardpath into the manifest without validating that it is a safe package-relative file reference. An attacker can supply parent-directory traversal, rooted paths, or absolute URIs instead of a card file within the plugin package.

The unsafe reference is propagated into the generated manifest. Its security effect depends on the downstream host's handling of the reference when the plugin is packaged and deployed. This is not local code execution or a file read performed by Kiota merely during generation. A consuming host that resolves the untrusted reference can cross the intended package boundary or use an unintended authentication card.

Affected versions

The affected NuGet packages are Microsoft.OpenApi.Kiota and Microsoft.OpenApi.Kiota.Builder, starting with version 1.25.1, which introduced this manifest field. The field remains unvalidated through version 1.34.1, including the separate 1.29.1 security-backport release. Version 1.35.0 fixes the issue.

Patches

Upgrade to Kiota 1.35.0 or later and regenerate affected plugin manifests. Kiota now applies the existing safe-file-reference validator to oauthcardpath, drops unsafe references, and emits a warning. Valid relative card paths remain supported.

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

Workarounds

Generate plugins only from trusted, integrity-protected OpenAPI descriptions. Before packaging or deployment, review generated manifests and remove any oauthcardpath that is not a safe relative reference confined to the plugin package. Do not rely on validation of sibling manifest fields to validate this field.

Related advisories

GHSA-4jwf-m4wg-8p66 and GHSA-p5rm-jg5c-8c77 cover statictemplate.file. Their fixes do not enforce validation at the separate oauthcardpath emission site.

A security flaw has been discovered in dotnet eShop .NET 8. The impacted element is the function GetOrderAsync of the file src/Ordering.API/Apis/OrdersApi.cs of the component Ordering API. Performing a manipulation of the argument OrderNumber results in improper control of resource identifiers. The attack is possible to be carried out remotely. The project was informed of the problem early through an issue report but has not responded yet.

Apache HTTP Server: limited RCE for some internal redirects to non-CGI files in CGI directories

Issue summary: SM2 signature generation uses non-constant-time arithmetic on secret values, forming a timing side-channel.

Issue summary: A non-constant-time optimized implementation of scalar point multiplication is used for SM2 private key operations on ARM64 and RISC-V platforms.

Issue summary: The generic elliptic-curve scalar multiplication used for ECDSA and SM2 signature operations with curves that do not have a dedicated implementation leaks information about the secret nonce through timing.

In the Linux kernel, the following vulnerability has been resolved:

RDMA/efa: Fix PBL chunk length computation

On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFAPTRSPERCHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length.

If the PBL number of pages is a multiple of EFAPTRSPERCHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration.

Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFAPTRSPERCHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.

In the Linux kernel, the following vulnerability has been resolved:

scsi: qla2xxx: Fix response queue over-consumption in qlaconsumeiocb()

qla24xxprocessresponsequeue() advances ringptr past the head IOCB before dispatching, so by the time qlaconsumeiocb() runs, ringptr already points at the first continuation IOCB. The function however looped purex->entrycount times starting at ringptr. As entrycount includes the head, this consumed one entry too many: it stamped RESPONSEPROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked.

Mark the head processed and account for it, then consume only the entrycount - 1 continuation IOCBs, matching qlacopypurextobuffer().

In the Linux kernel, the following vulnerability has been resolved:

signal: avoid shared siginfo namespace rewrites

sendsignallocked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next.

Copy the siginfo before changing it.

In the Linux kernel, the following vulnerability has been resolved:

of: fix out-of-bounds read in ofaliasscan() stem parser

The stem parser tests isdigit((end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.

Bluetooth: hcicore: use skbget() instead of skbclone() for reqskb

Fixed (Various packet overreads in mysqlnd wire protocol). (CVE-2025-1218)

Uninitialized resource in Media in Google Chrome on on Windows prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High)

Chromium CVE-2026-93378: Missing authorization in Storage

Chromium CVE-2026-93380: Race condition in FileSystem

In the Linux kernel, the following vulnerability has been resolved:

smack: fix incorrect task context in smackmsgqueuemsgrcv

The smackmsgqueuemsgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task.

In the msgsnd() syscall path, if a receiver is already waiting, the pipelinedsend() optimization is used to push the message directly to the receiver task:

ipc/msg.cpipelinedsend(): smpstorerelease(&msr->rmsg, msg)

In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->rtsk, passed as the 'target' parameter):

ipc/msg.cpipelinedsend(): securitymsgqueuemsgrcv(,, target := msr->rtsk,,)

However, smackmsgqueuemsgrcv() ignores the 'target' and checks 'current':

smackmsgqueuemsgrcv(…) smkcuraccmsq(isp, MAYREADWRITE); // current task

'current' MAY satisfy smackmsgqueuemsgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy.

Test: 1) create a sysv message queue with label “foo” 2) echo "bar foo r" >/smack/load2 3) msgrcv(,,,0,MSGNOERROR) in "bar"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a "foo"-labeled task: "bar"-labeled task gets the message.

This patch fixes the issue by checking permission on the 'target' task instead of 'current'.

(2008-02-04, Casey Schaufler)

Summary

OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.

The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.

Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.

Details

When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:

1. the provider's span processors; 2. each processor's span exporter; and 3. for the OTLP trace exporter, its client configuration.

This causes the following values to be present in the event:

- OTLP trace gRPC: the configured endpoint; - OTLP trace HTTP: the configured endpoint and the Insecure flag; and - Zipkin: the complete collector URL.

OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:

- versions 1.5.0 through 1.14.x use V(1) for this Info event; and - versions 1.15.0 through 1.44.0 use V(4).

OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.

Proof of concept

The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:

go package main

import ( "bytes" "context" "fmt"

"github.com/go-logr/logr/funcr" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/exporters/zipkin" sdktrace "go.opentelemetry.io/otel/sdk/trace" )

func main() { var logs bytes.Buffer otel.SetLogger(funcr.New(func(, args string) { , = logs.WriteString(args) }, funcr.Options{Verbosity: 4}))

exporter, err := zipkin.New( "http://user:pass@zipkin.internal:9411/api/v2/spans?token=secret", ) if err != nil { panic(err) }

tp := sdktrace.NewTracerProvider(sdktrace.WithBatcher(exporter)) = tp.Shutdown(context.Background())

fmt.Println(logs.String()) }

The TracerProvider created event contains:

text http://user:pass@zipkin.internal:9411/api/v2/spans?token=secret

For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.

Impact

This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.

There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.

Remediation

Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.

If an immediate upgrade is not possible:

- keep OpenTelemetry internal logging below the Info verbosity described above; - do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and - restrict access to existing logs and rotate any credentials that may already have been recorded.

'serve-expired' can bypass Unbound 'wait-limit'

Chromium CVE-2026-91730: Incomplete cleanup

Chromium CVE-2026-91708: Race condition

Chromium CVE-2026-91747: Use after free

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.

HID: picolcd: clamp eeprom debugfs read to bytes actually received

HID: roccat: free buffered reports when destroying device

bnx2x: fix double free in bnx2xinitfirmware() error path

In the Linux kernel, the following vulnerability has been resolved:

ipip: fix skb leak in collectmd mode when metadatadst allocation fails

In collectmd mode ipiptunnelrcv() returns 0 without freeing the skb when iptunrxdst() fails to allocate the metadatadst. ipiprcv() and mplsiprcv() are registered as xfrmtunnel handlers, so tunnel4rcv() and tunnelmpls4rcv() read the zero return as "the packet has been consumed" and do not free it either. The skb is leaked.

The other tunnel drivers all dispose of the packet at this point: ip6tunnel.c jumps to its drop label, ipgre.c and ip6gre.c return PACKETREJECT, which makes grercv() free the skb. Only ipip returns 0.

Jump to the existing drop label instead. It frees the skb and still returns 0, so the packet keeps being reported as consumed, which is what we want here: the outer header has already been pulled, and neither the remaining handlers nor an ICMP unreachable have any use for it.

Triggering this needs an ipip or mplsip tunnel in collectmd mode and an atomic allocation failure, which is why it has gone unnoticed.

In the Linux kernel, the following vulnerability has been resolved:

power: supply: bq25890: Fix powersupply reference leak

bq25890fwprobe() acquires a reference to a secondary charger using powersupplygetbyname(), but the reference is not released on later probe failures or on driver detach.

In particular, failures after bq25890fwprobe() returns successfully, such as a failure in bq25890hwinit(), also leak the reference.

Register a device-managed cleanup action immediately after acquiring the secondary charger. This releases the reference on all subsequent probe failures and on driver detach.

Found by code review.

In the Linux kernel, the following vulnerability has been resolved:

power: supply: max17040: synchronize work cancellation on suspend

max17040work() requeues itself after every poll. canceldelayedwork() only cancels a pending instance and does not wait for a callback that is already running.

If system suspend races with the polling callback, the callback can continue accessing the fuel gauge and requeue itself after the suspend callback returns.

Use canceldelayedworksync() to ensure polling is quiesced before suspend completes.

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix socket refcount leak in smcswitchconns()

smcswitchconns() takes a reference on the SMC socket before dropping lgr->connslock, so the connection stays alive while the CDC slot is fetched:

sockhold(&smc->sk); readunlockbh(&lgr->connslock); / pre-fetch buffer outside of sendlock, might sleep / rc = smccdcgetfreeslot(conn, tolnk, &wrbuf, NULL, &pend); if (rc) goto errout;

The errout label only drops the wrtx link reference, so this early exit returns without the matching sockput(). The second error exit is not affected, because sockput() has already run by then.

A leaked skrefcnt means the smcsock is never destroyed. Its send and receive buffers stay allocated, and for a user socket the reference held on the network namespace is never released, so the netns can no longer be torn down.

smccdcgetfreeslot() fails when the target link goes down or when the connection has been killed while the switch is in progress. Both are reachable during the link failover this function implements, so the leak is triggered by the same hardware events that make smcswitchconns() run in the first place.

Restructure so there is a single sockput() covering both outcomes, instead of adding a second one to the error path.

In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: Fix memory leak in brcmfsdioreadcontrol()

The memory allocated for buf is not freed in some of the error paths in brcmfsdioreadcontrol(). Fix that by adding vfree() calls.

[arend: rework as suggested by Johannes]