YARA-X’s 1.18.0 release brings 3 improvements and 2 bugfixes.
One of the improvements is a new command-line option, –cpu-limit, allowing one to limit the amount of CPU YARA requires.
YARA-X’s 1.19.0 release brings 4 improvements and 2 bugfixes.
Didier Stevens
Senior handler
blog.DidierStevens.com
A high-severity flaw in Amazon Q Developer let a malicious repository run commands and steal a developer’s cloud credentials. The path was short: a developer opens the repo, trusts the workspace, and Amazon Q does the rest. Amazon has patched it.
Tracked as CVE-2026-12957 (CVSS 8.5), the bug sat in how Amazon’s AI coding assistant handled Model Context Protocol (MCP) servers.
Wiz Research, which found and reported it, showed that a single config file dropped in a repo was enough to go from git clone to cloud compromise.
Amazon Q read an MCP configuration file, .amazonq/mcp.json, from the open workspace and launched the servers it defined. MCP servers are local processes that an AI assistant can spawn to reach databases, APIs, or build tools, so starting one means running commands on the machine.
Those processes inherited the developer’s full environment. That usually means AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets.
Put the two together, and a file sitting in a cloned repo could run arbitrary code with the developer’s live cloud session attached. No password, no second sign-in.
In its proof of concept, Wiz had the file run aws sts get-caller-identity and ship the output to an attacker server, capturing the active AWS session. What comes next depends on that developer’s cloud permissions: backdoor an IAM user for persistence, reach internal services, or pivot toward production.
AWS and Wiz frame the consent step differently. Amazon’s advisory says the user has to trust the workspace when prompted, and CVSS rates the user interaction as passive.
Wiz reported there was no separate consent step for the MCP servers themselves before the fix. The patch closes that gap: Amazon Q now flags an untrusted MCP server and lets the developer reject the command before it runs.
The flaw lives in Language Servers for AWS, the runtime that powers Amazon Q across VS Code, JetBrains, Eclipse, and Visual Studio. All four plugins bundle it, so all four were exposed by versions that shipped an older copy.
Update. CVE-2026-12957 is fixed in Language Servers for AWS 1.65.0, but AWS’s bulletin tells customers to move to 1.69.0.
That build also closes a second issue, CVE-2026-12958, a missing symlink check that could allow arbitrary file writes outside the workspace trust boundary.
The patched plugin minimums:
The language server auto-updates unless the network blocks it, and reloading the IDE pulls the latest build.
There is no known public exploitation; CISA’s ADP entry for CVE-2026-12957 lists it as none. Wiz found the flaw through research and disclosed it in coordination with Amazon, reporting it on April 20 and seeing a fix on May 12, ahead of the June 26 public write-up.
Amazon Q is not the first coding assistant to trip over MCP trust. The bugs are not identical, but they rhyme: project configuration turns into executable behavior, and the trust checks around that handoff keep failing.
Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) both had project-level MCP config that led to command execution. Windsurf (CVE-2026-30615) reached the same end by a different path, with attacker-controlled content rewriting the local MCP config to register a malicious server.
The convenience of letting a project folder configure an AI agent is also the attack surface. Repo-carried config is untrusted input. Turning it into a running process should take an explicit yes.
A flaw in the Linux kernel’s traffic-control subsystem can let a local unprivileged user gain root on affected systems.
CVE-2026-46331, nicknamed “pedit COW,” is an out-of-bounds write in the packet-editing action (act_pedit) that corrupts shared page-cache memory. A public, working exploit appeared within a day of the CVE assignment on June 16. Red Hat rates the flaw as important.
The exploit never touches the file on disk. It poisons the cached copy of a setuid root binary (/bin/su) in memory, injects a small payload, and runs that altered image as root. File-integrity checks come back clean while a root shell is already open.
The exploit needs two things: act_pedit being loadable and unprivileged user namespaces being open, giving the attacker a namespace-local networking capability (CAP_NET_ADMIN) needed to trigger the bug.
On the tested RHEL and Debian targets, both conditions were present.
Linux’s tc traffic-control tool can rewrite packet headers in flight using an action called pedit. The kernel function that does this, tcf_pedit_act(), is supposed to make a private copy of the data before editing it, the standard copy-on-write pattern.
It checked the writable range once, before the final offsets were known. Some edit keys only resolve their offset at runtime. When that happens, the write lands outside the privately copied region, so the kernel modifies a shared page-cache page instead of a private copy. If that page belongs to a cached file, the file’s in-memory image is corrupted.
The pattern is familiar. Dirty Pipe, Copy Fail, DirtyClone, and Dirty Frag all share the same shape: a kernel fast path writes into a page it does not exclusively own, and the page cache takes the hit.
What is new here is the entry point. An unprivileged user can configure tc actions from inside a user namespace, which gives them the CAP_NET_ADMIN that the exploit needs.
The PoC author reported unprivileged-to-root exploitation on RHEL 10 and Debian 13 (trixie), where unprivileged user namespaces are open by default. Ubuntu 24.04 required routing execution through AppArmor profiles that still permit user namespaces. Ubuntu 26.04 blocks that path by default because its AppArmor profiles restrict unprivileged user namespaces, though the underlying kernel remains vulnerable.
Fixes are split by vendor.
Install the patched kernel and reboot. Prioritize systems where “local user” does not mean trusted user: multi-tenant hosts, CI/CD runners, Kubernetes nodes, build workers, and shared research or lab machines.
If you cannot patch yet, two mitigations kill the exploit chain. On systems that do not need tc pedit rules, check whether the module is in use (lsmod | grep act_pedit), then block it from loading:
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.confAlternatively, disable unprivileged user namespaces (user.max_user_namespaces=0 on RHEL, kernel.unprivileged_userns_clone=0 on Debian/Ubuntu). That removes the namespace-local capability the exploit needs, but it breaks rootless containers, some CI sandboxes, and sandboxed browsers. Test first.
Because the overwrite targets cached memory, file-integrity checks may not catch it. Dropping the page cache (echo 3 > /proc/sys/vm/drop_caches) clears the poisoned in-memory copy, but does nothing about the root shell the attacker already opened. Treat the host as compromised.
The fix landed on the netdev mailing list in late May, framed as a routine data-corruption patch. The exploitable detail sat on a public mailing list for weeks. No CVE, no security warning. The CVE was assigned when the fix was merged on June 16. The weaponized proof-of-concept followed within a day. For kernel page-cache corruption bugs, waiting for a scanner rule is too slow.