A malicious file identified by the SHA-256 hash 5bb52bd682510c1fdc91025512a92c0e2323c885664e65ad32f0fbb426940469 was observed by OffSeq Mirage honeypot sensors on 2026-10-26. The file was detected four times during attacker activity involving the T1105 technique (Ingress Tool Transfer), indicating it was used to stage or deliver a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The malicious activity was traced to attacker infrastructure located in PS. Organizations are advised to match this hash against their environments and security feeds to detect potential compromise.
A malicious file identified by the SHA-256 hash a863e21577e54cd763729803a621804da4b5030afa35bcf879ea3b3413488a66 was observed by OffSeq Mirage honeypot sensors during attacker activity on 2026-10-26. This file is associated with CVE-2026-109618 and linked to the MITRE ATT&CK technique T1105 (Ingress Tool Transfer). The file likely represents a malicious payload such as a dropper, web shell, miner, or post-exploitation tool used during the attack. The activity was traced back to attacker infrastructure in PS. Organizations are advised to match this hash against files in their environments and threat intelligence feeds.
CVE-2026-85297 is a vulnerability in Google Cloud Run MCP versions prior to 1.11.0 that allows bucket squatting. This flaw enables attackers to intercept and access proprietary source code, execute arbitrary code, and exfiltrate data. The issue is resolved in version 1.11.0 and later.
The PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) are critical flaws in the PHP engine allowing unauthenticated remote code execution. Multiple industrial vendors including Siemens, Schneider Electric, ABB, and others have confirmed that some of their products are affected. Patches for PHP were released on October 21, 2026, shortly after exploitation attempts began. Several vendors have released or are preparing patches for affected products, while some continue to assess impact or provide mitigations. The vulnerabilities have been actively targeted in the wild, with millions of exploitation attempts reported and confirmed attacks on honeypots.
CVE-2026-99099 addresses a vulnerability in the Linux kernel related to AMD processors where the processor may fail to invalidate a TLB entry when executing an INVLPGB/TLBSYNC instruction pair. This issue is known as AMD TLBI Erratum #1718. The Linux kernel has implemented a software workaround to detect this erratum and mitigate it when a microcode fix is not available.
A buffer overflow vulnerability in the Linux kernel's dm-integrity inline mode with large tag sizes has been fixed. The issue occurs because the checksum computation uses an on-stack buffer smaller than the tag size, causing an overflow when the tag size exceeds the buffer size. This overflow can cause kernel panics with stack protection enabled. The vulnerability requires root privileges to trigger and is not considered a security bug. Fixes have been applied in recent kernel commits.
A vulnerability in the Linux kernel's tee subsystem allows zero-sized allocations in tee_dyn_shm_alloc_helper(), leading to a kernel allocation failure and potential boot panic on systems with panic_on_warn enabled. This occurs because the function does not check for zero size before calling alloc_pages_exact(), which results in an invalid page order. The issue is triggered via TEE_IOC_SHM_ALLOC with a zero size parameter and has been fixed in specific commits.
A vulnerability in the Linux kernel's io_uring subsystem allowed disabled rings to bypass task restrictions on register operations until enabled. This could let a task with restricted register opcodes create a disabled ring, perform any register opcode on it, and then enable the ring without proper permission. The issue has been fixed by ensuring that rings inheriting restrictions from tasks are checked even while disabled, requiring explicit permission to enable them.
A vulnerability in the Linux kernel's drm/vc4 driver was fixed by properly draining the hangcheck timer and related work on V3D unbind. The flaw allowed timer callbacks to access freed memory due to the timer not being stopped before the device was unbound and freed.
A vulnerability in the Linux kernel Bluetooth driver btintel_pcie was fixed to correct a bounds check error in the TX descriptor handling. The function btintel_pcie_prepare_tx used an index that could exceed the valid range of the transmit queue arrays, potentially leading to out-of-bounds access. This issue was addressed by rejecting an index equal to the transmit queue count, which is one past the end of the arrays.
A Linux kernel vulnerability was fixed that prevented scheduling deferred kernel page table freeing during system boot. The issue caused kernel panics when using a boot-time function tracer with a filter, due to workqueue usage before initialization. The fix delays scheduling the freeing work until the system is fully booted.
CVE-2026-99092 is a vulnerability in the Linux kernel affecting the riscv architecture's handling of bpf-jit execmem addresses. The issue arises from incorrect assumptions about memory writability in the vmalloc area when CONFIG_STRICT_MODULE_RWX is disabled, causing BPF JIT compilation to fail. This bug affects kernel version 6.10 and similar configurations where strict module RWX enforcement is not enabled. The flaw has been fixed in specific commits addressing the patch_map() function to correctly handle executable memory mappings for BPF JIT code.
A vulnerability in the Linux kernel Bluetooth management (MGMT) subsystem caused pending commands flushed on power off to report an incorrect status. Specifically, commands pending when the Bluetooth adapter powers off were incorrectly answered with a success status (0x00) instead of the appropriate error status (e.g., Not Powered or Invalid Index). This could cause user-space components like bluetoothd to crash due to unexpected responses. The issue has been fixed in Linux kernel versions 6.6.160, 6.2, 6.11, 6.12, and related releases.
CVE-2026-99090 is a vulnerability in the Linux kernel's AMDGPU driver where vblank counter reads are not properly serialized against GPU resets. This can cause unsafe hardware access during GPU recovery, triggering kernel warnings and tainting the kernel. The issue is fixed by acquiring a semaphore before hardware access or returning a cached software count if reset is in progress.
A vulnerability in the Linux kernel's ASoC Samsung i2s driver causes an imbalance in runtime power management due to the op_clk clock not being enabled during device probe. This leads to a warning during boot related to clock disablement. The issue is fixed by enabling op_clk in the probe function and disabling it in the remove function.
A vulnerability in the Linux kernel's Open vSwitch component related to IPv6 address rewrite actions on IPv6 fragments has been fixed. The issue occurs because the transport header is not properly validated before being accessed, leading to uninitialized memory reads that trigger warnings under debug configurations. The fix involves early return in the checksum update function to avoid reading uninitialized transport header offsets for IPv6 fragments.
Improper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component.
This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2.
XQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel's own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.
rhc is a client tool and daemon that connects the system to Red Hat hosted services enabling system and subscription management.
Security Fix(es):
* net/http: golang: golang: Denial of Service via crafted HTTP Range headers (CVE-2026-78667)
* crypto/tls: golang: crypto/tls: Denial of Service via multiple ECH outer extension references (CVE-2026-97031)
* net/http: net/http/internal/http2: golang.org/x/net/http2: net/http: Denial of Service via excessive HTTP/2 SETTINGS frames (CVE-2026-78669)
* crypto/x509: golang: crypto/x509: Man-in-the-middle attacks via untrusted intermediate certificates (CVE-2026-111943)
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.
The boneIO Black web interface lacks proper clickjacking protections. A remote attacker can embed the control panel in an iframe on a malicious web page and trick an authenticated user on the internal network into clicking buttons that activate relays, open gates, or control blinds. This can lead to unauthorized state changes with potential physical safety consequences. Critically, due to CVE-2026-77053 (authentication disabled by default), any user on the same internal network can trigger attacker-controlled actions by visiting the malicious website.
This issue was fixed in version 1.6.0.
Use of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component.
This issue affects Apache Camel: from 4.19.0 before 4.22.2.
OAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile's scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token's audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret.
Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile’s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.