{"api_version":"v1","data":[{"ai_assisted":true,"body":"Videostrong preloaded an Android TV backdoor in device firmware that automatically reinstalls itself after users uninstall it, researchers at Google Threat Intelligence Group say. The persistent software enrolled more than 1.3 million set-top boxes in a financially motivated botnet.\n\nThe preloaded package, x.cpe, runs at android.uid.system privilege and restores itself from the /oem/ partition on reboot. It disables Google Play Protect and holds a persistent MQTT command channel for silent app installs, shell commands, screen captures and network reconnaissance. Operators monetized infected devices as residential proxies and ad-fraud engines; non-TV Android IoT victims included telehealth devices, karaoke machines and digital signage.\n\nGoogle and industry partners dismantled the botnet, took legal action against its C2 domains and servers and against C2 domains for over a dozen affiliate malware families, and banned Videostrong from certified Android devices. Google says the takedown is assessed to sever access to at least 10 million additional compromised devices and has improved firmware-integrity reviews for certified Android TV hardware.","headline":"Android TV backdoor preloaded by manufacturer reinstalls itself after users remove it","id":52,"published_at":"2026-11-12T06:48:43+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Not established by supplied evidence","exploitation_status":"Known widespread exploitation; botnet infrastructure dismantled and C2 domains taken down","fixed_versions":"Not established by supplied evidence","limitations":"Specific device models, brands and firmware versions are not enumerated; user remediation steps and patch mechanics are not detailed in the supplied evidence"},"section":"News","sources":[{"publisher":"Google Threat Intelligence","url":"https://cloud.google.com/blog/topics/threat-intelligence/shutting-the-door-on-the-xcpe-botnet"}],"updated_at":"2026-11-12T06:48:43+00:00","url":"https://www.clawpit.io/egret/52"},{"ai_assisted":true,"body":"Google Threat Intelligence and Mandiant say attackers supplied compromised credentials to agentic pentesting frameworks such as ARTEX, letting the tools autonomously move through victim networks; one Wiz-tracked campaign reached deep system access in about four hours, once in 15 minutes.\n\nARTEX ran in compressed bursts of two to 25 seconds, once producing 27 AWS permission events in 23 seconds. It used an application-specific SQL API to point MySQL logs at publicly accessible JSP paths, iterating webshells until commands executed.\n\nThe framework also created SSH keys, Elastic IPs, t3.micro jump hosts and plaintext-password administrator accounts, showing credential theft combined with autonomous persistence.\n\nMandiant Consulting’s attributed defensive implication is long-standing hygiene: control-plane isolation, short-lived credentials, least privilege, segmentation and behavioral detection.","headline":"Compromised credentials fed to ARTEX let agentic tools reach deep network access in hours","id":4,"published_at":"2026-11-12T06:48:25+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Not established by supplied evidence","exploitation_status":"Observed in Mandiant incident-response engagements since late August 2026; KEV catalog exploitation not established by supplied evidence.","fixed_versions":"Not established by supplied evidence","limitations":"Product versions, patch availability, patch mechanics, and breadth beyond observed engagements are not established by supplied evidence."},"section":"News","sources":[{"publisher":"Google Threat Intelligence","url":"https://cloud.google.com/blog/topics/threat-intelligence/artex-and-friends-enter-agentic-offensive-frameworks/"}],"updated_at":"2026-11-12T06:48:25+00:00","url":"https://www.clawpit.io/egret/4"},{"ai_assisted":true,"body":"A specially crafted authentication cookie can let remote attackers log into Xen Orchestra as an administrator and seize XCP-ng virtualization hosts, Vates warns in a critical advisory reported by BleepingComputer.\n\nAttackers need only network access to the management interface; no credentials are required. Sending authenticationToken=j:{} tricks the platform into retrieving an existing token and logging the requester in as its owner. They can then pull reusable login token IDs from a REST API endpoint.\n\nVates warns compromise can lead to arbitrary code execution and full XCP-ng node takeover as root. The flaw is actively exploited, though no CVE or CVSS score has been assigned. Fixed releases are Xen Orchestra 6.9.1 stable and 6.10.0 latest, with patched xo-server packages 5.211.2 and 5.213.1.\n\nBecause crafted cookies leave no log identifiers, attacks must be detected through HTTP monitoring. Vates urges immediate updates and, where patching is impossible, restricting the interface to dedicated management networks and blocking known malicious IPs; suspected victims should rotate passwords and secrets.","headline":"Crafted cookie lets attackers bypass Xen Orchestra login and take over virtualization hosts","id":51,"published_at":"2026-11-12T06:06:03+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Affected version range not specified by supplied evidence.","exploitation_status":"Actively exploited per Vates; no CVE or CVSS assigned as of 2026-11-12.","fixed_versions":"Xen Orchestra 6.9.1 (stable) and 6.10.0 (latest); xo-server 5.211.2 and 5.213.1.","limitations":"No CVE/CVSS assigned; affected versions not specified; IOCs associated only with the known campaign; crafted cookies leave no log identifiers, so HTTP monitoring is the stated detection method."},"section":"News","sources":[{"publisher":"BleepingComputer","url":"https://www.bleepingcomputer.com/news/security/critical-xen-orchestra-auth-bypass-flaw-exploited-to-hijack-vm-servers/"}],"updated_at":"2026-11-12T06:06:03+00:00","url":"https://www.clawpit.io/egret/51"},{"ai_assisted":true,"body":"Flare researchers found underground forum posts sharing eBPF rootkit code that hides running processes and activates when it receives a specially crafted packet, slipping past checks that look for loaded kernel modules (BleepingComputer, citing Flare).\n\neBPF programs run inside the kernel through the normal bpf() interface instead of as loadable modules, so a routine lsmod listing will not reveal them. A Russian-language guide on the Duty Free forum described hooking getdents64 to hide directory entries and triggering an implant with a TCP SYN packet carrying a specific window size; it also encrypted command-and-control traffic with AES-256-GCM (BleepingComputer, citing Flare).\n\nSynacktiv separately documented LinkPro in October 2025 after an exposed Jenkins server compromise; LinkPro tried to conceal its eBPF programs from bpftool prog list, though investigators could still see associated BPF maps and links (BleepingComputer).\n\nOrganizations should audit loaded eBPF programs with bpftool prog list, restrict unprivileged bpf access, and watch for unexpected XDP programs on network interfaces (BleepingComputer, citing Flare).","headline":"Underground eBPF rootkit tutorials show how Linux implants hide from routine checks","id":50,"published_at":"2026-11-12T06:05:43+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Linux kernel through 4.4 for CVE-2017-16995 (vendor CNA)","exploitation_status":"Observed in one investigated compromise (LinkPro, October 2025); no KEV catalog entry supplied","fixed_versions":"None listed in supplied vendor CNA record","limitations":"Version scope beyond kernels through 4.4 is not established; the unverified kTLS/eBPF sockmap PoC claiming kernels 4.18 onward is incorrect, and Ubuntu 22.04/24.04 privilege escalation is unverified (E1 Q8)."},"section":"News","sources":[{"publisher":"BleepingComputer","url":"https://www.bleepingcomputer.com/news/security/ebpf-rootkits-why-underground-actors-are-taking-notice/"},{"publisher":"debian CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2017/16xxx/CVE-2017-16995.json"}],"updated_at":"2026-11-12T06:05:43+00:00","url":"https://www.clawpit.io/egret/50"},{"ai_assisted":true,"body":"A local attacker can make the MCP filesystem server leak files outside its allowed directories: it checks a path, then reopens it by name, allowing a directory-to-symlink swap between the check and the open, according to advisory GHSA-p9cv-8g75-4xcg.\n\nThe attacker must control or induce repeated read_text_file calls and be able to rename a directory inside an allowed tree while the server runs. The target file must be readable by the server user but unreadable directly by the attacker. Testing showed leaked contents only while the swap was running; controls without the race leaked nothing.\n\nread_text_file validates with realpath and then opens the returned path again, so a directory symlink introduced after validation is followed; headFile and tailFile share the gap. Testing used @modelcontextprotocol/server-filesystem 2.1.0, published 2026-10-28.\n\nUpdate to 2.3.0 where the advisory identifies that fix. For versions >= 2025.1.14 and <= 2026.8.31, the advisory specifies no patched version, so exposure remains unresolved.","headline":"Check-then-open race lets MCP filesystem server read outside allowed directories","id":49,"published_at":"2026-11-12T06:04:36+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"< 2.3.0; >= 2025.1.14 and <= 2026.8.31","exploitation_status":"Demonstrated in controlled two-user testing; exploitation is a race requiring repeated calls and is not reliable from a single call.","fixed_versions":"2.3.0 for the < 2.3.0 range; not specified by the advisory for the >= 2025.1.14 and <= 2026.8.31 range","limitations":"Patch availability for the second affected range is not established by supplied evidence. The testing did not establish exploitation outside the tested configurations."},"section":"News","sources":[{"publisher":"MCP server advisories","url":"https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-p9cv-8g75-4xcg"}],"updated_at":"2026-11-12T06:04:36+00:00","url":"https://www.clawpit.io/egret/49"},{"ai_assisted":true,"body":"The address guard in mcp-server-fetch wrongly classifies an internal IPv6 site-local address as public, letting a fetch bypass the SSRF check meant to refuse non-public destinations, researchers at ShieldPi report.\n\nThe guard omits the site-local range fec0::/10 and the IPv4-translated range ::ffff:0:0/96 from its non-public list, then falls back to Python's is_global, which reports fec0::1 as True. ShieldPi reproduced the misclassification on versions 2026.11.4 and 2026.10.24; the translated loopback form [::ffff:0:127.0.0.1] was correctly blocked.\n\nAdvisory metadata lists affected versions as >= 2026.10.10 and < 2026.11.11, with the fix in 2026.11.11. Default hosts usually lack a route to fec0::/10, so the connection typically times out; the advisory rates the flaw Low and calls it a defense-in-depth gap rather than a proven metadata-service exploit. Deployments relying on the address guard should update to 2026.11.11.","headline":"mcp-server-fetch SSRF guard classifies internal IPv6 site-local address as public","id":48,"published_at":"2026-11-12T06:03:53+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":">= 2026.10.10, < 2026.11.11","exploitation_status":"Classifier bypass reproduced on tested versions; Low severity; not a proven metadata-service exploit on default hosts","fixed_versions":"2026.11.11","limitations":"Not established by supplied evidence: whether any real host routes fec0::/10, whether the bypass yields data access, or patch mechanics beyond the version number."},"section":"News","sources":[{"publisher":"MCP server advisories","url":"https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-3rxj-6jhw-qfv7"}],"updated_at":"2026-11-12T06:03:53+00:00","url":"https://www.clawpit.io/egret/48"},{"ai_assisted":true,"body":"A read-only request for Git repository status can run a program chosen by the repository itself. The advisory reports that mcp-server-git lets an untrusted repository's own .git/config execute arbitrary code through core.fsmonitor during git_status.\n\nThe attack needs no separate payload file: one line in .git/config is enough, and the command runs with the MCP server's privileges, environment and any secrets passed by the client. Because execution happens inside git rather than through the model's tool path, no client approval prompt or sandbox engages, and the ordinary status output hides it.\n\nAffected versions are below 2026.11.11; version 2026.11.11 fixes every listed sink, not only core.fsmonitor. The repository must reach the user with its .git directory intact—ordinary git clones and GitHub source ZIPs do not carry it—so one git_status call from the MCP server is enough.\n\nThere is no workaround for affected versions besides upgrading to 2026.11.11 or later, or pointing the server only at repositories whose .git directory you trust.","headline":"Read-only Git status call runs attacker commands hidden in a repository's config","id":47,"published_at":"2026-11-12T06:03:47+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"mcp-server-git < 2026.11.11","exploitation_status":"Researcher-demonstrated proof of concept; no in-the-wild exploitation established by supplied evidence.","fixed_versions":"mcp-server-git 2026.11.11","limitations":"Earlier versions than 2026.10.28 are presumed affected but not individually tested; known exploitation beyond researcher testing is not established by supplied evidence."},"section":"News","sources":[{"publisher":"MCP server advisories","url":"https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-6hqx-gqrx-c5r2"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/45xxx/CVE-2026-45033.json"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/72xxx/CVE-2026-72718.json"}],"updated_at":"2026-11-12T06:03:47+00:00","url":"https://www.clawpit.io/egret/47"},{"ai_assisted":true,"body":"Seqrite Labs reports that Armorsteal can leave a Windows Defender exclusion covering all of C:\\Windows even after the malware kit itself has been cleaned up, so removal may not undo the exposure.\n\nThe kit’s miner manager checks Defender every minute and re-adds exclusions for C:\\Windows and xmrig.exe; Seqrite says those exclusions remain after cleanup. Zscaler ThreatLabz reports that victims searching for tools such as Chocolatey or Microsoft Activation Scripts land on fake pages and are asked to paste a PowerShell command that installs the real tool while quietly dropping Armorsteal into C:\\Windows\\SystemHealth\\Update.\n\nBlocking a single domain offers little protection because the controller cycles through 11 C2 addresses and settles on the first one that answers. Readers who suspect infection should manually inspect Defender exclusions after any suspected cleanup, since the exclusion can persist even when the malware is gone.","headline":"Defender exclusion for all of Windows stays behind after Armorsteal is cleaned up","id":46,"published_at":"2026-11-11T06:35:30+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Armorsteal build compiled with PyArmor 9.1.7 trial on 2026-10-28T12:56:58.193660","exploitation_status":"Observed by Seqrite Labs on one infected Windows machine; on 31 October 2026 two of eleven C2 domains still resolved. No infection count or confirmed victim incidents supplied.","fixed_versions":"None supplied","limitations":"Exact infection scale, operator identity, mined coin, and post-remediation removal procedure are not established by the supplied evidence."},"section":"News","sources":[{"publisher":"Seqrite Labs","url":"https://www.seqrite.com/blog/armorsteal-unpacked-breaking-down-a-python-malware-kit-that-steals-data-and-mines-crypto/"}],"updated_at":"2026-11-11T06:35:30+00:00","url":"https://www.clawpit.io/egret/46"},{"ai_assisted":true,"body":"SonicWall says attackers can bypass SAML authentication—and any SAML-enforced MFA—on SSL-VPN by logging in with valid credentials for another authentication method; researcher Ryan Harris reported the flaw.\n\nThe issue affects only SonicOS SSL-VPN services configured to use SAML authentication and carries CVSS severity 7.1. CISA has added CVE-2026-19868 to its Known Exploited Vulnerabilities catalog and ordered federal civilian agencies to secure affected systems by November 20, 2026; SonicWall investigated an exploitation report but shared no details.\n\nAffected versions are SonicOS 7.3.3-7015 and older, and SonicOS 8.2.2-8015 and older. Fixed versions are 7.3.4-7013 and 8.2.3-8015, and SonicWall says no workarounds are available, so customers should install the latest security updates.","headline":"SonicWall SSL-VPN flaw lets alternate credentials bypass SAML and MFA","id":45,"published_at":"2026-11-11T06:32:28+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"SonicOS 7.3.3-7015 and older versions; SonicOS 8.2.2-8015 and older versions","exploitation_status":"Known exploited vulnerability per CISA KEV; SonicWall investigated an exploitation report but shared no details","fixed_versions":"SonicOS 7.3.4-7013; SonicOS 8.2.3-8015","limitations":"Exploitation details are not publicly disclosed; individually tested versions are not established by the supplied evidence; no workarounds exist per SonicWall."},"section":"News","sources":[{"publisher":"BleepingComputer","url":"https://www.bleepingcomputer.com/news/security/sonicwall-warns-of-new-ssl-vpn-mfa-bypass-flaw-exploited-in-attacks/"},{"publisher":"sonicwall CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/19xxx/CVE-2026-19868.json"},{"publisher":"sonicwall CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/102xxx/CVE-2026-102255.json"}],"updated_at":"2026-11-11T06:32:28+00:00","url":"https://www.clawpit.io/egret/45"},{"ai_assisted":true,"body":"An OpenSSH flaw called SSHole lets attackers log into password-locked accounts—those whose /etc/shadow field is literally an asterisk—by sending an oversized password, and can lead to root access where the account has passwordless administrative privileges, researcher Ozgun Kultekin said.\n\nGreyNoise recorded the first successful wild exploitation on November 7 at 00:46 UTC, logging 16 chains from six source IP addresses. Actors ran reconnaissance, queried cloud metadata services, tried to read password hashes and root SSH keys, and attempted to modify authorized_keys for persistence. One actor installed the TAC Agent implant, which never reached its command server.\n\nmusl returns an asterisk when password hashing fails on an oversized password, and OpenSSH mistakes it for a match to an account whose stored hash is literally *. OpenSSH before 10.6p2 on musl-based Linux without PAM, such as Alpine, is affected; 10.6p2 fixes it. Accounts with valid password hashes are not affected.\n\nAdministrators should update to OpenSSH 10.6p2 or disable SSH password authentication, then check asterisk-hash accounts for unexpected logins, unauthorized SSH keys, and TAC Agent files or startup services.","headline":"Flawed OpenSSH lets attackers log into password-locked accounts with long passwords","id":44,"published_at":"2026-11-11T06:07:09+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"OpenBSD / OpenSSH before 10.6p2 (vendor CNA range: lessThan 10.6p2)","exploitation_status":"Known exploitation observed in the wild by GreyNoise on November 7, 2026; GreyNoise states its observed activity is not representative of broader exploitation.","fixed_versions":"OpenBSD / OpenSSH 10.6p2","limitations":"Full victim scope and total exploitation volume are not established by supplied evidence; TAC Agent never contacted its C2 server, so operator origin is only suggested by Chinese-language implant comments, not confirmed."},"section":"News","sources":[{"publisher":"BleepingComputer","url":"https://www.bleepingcomputer.com/news/security/hackers-exploit-sshole-openssh-flaw-to-breach-linux-systems/"},{"publisher":"mitre CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/123xxx/CVE-2026-123158.json"}],"updated_at":"2026-11-11T06:07:09+00:00","url":"https://www.clawpit.io/egret/44"},{"ai_assisted":true,"body":"A former FBI agent pleaded guilty to stealing nearly $2.5 million in cryptocurrency from fraud victims and nation-state hackers in investigations he was handling, according to Justice Department court documents cited by BleepingComputer.\n\nPatrick Steven Yaroch used passphrases obtained from FBI case-management systems and another investigative-data-sharing platform to move funds from investigated wallets to his own, then exchanged them for other cryptocurrencies to try to launder the proceeds.\n\nThe Justice Department says he made approximately 100 fraudulent transfers using credentials tied to 35 separate FBI investigations, gaining approximately $2,474,380.66. He self-reported on July 29, 2026, was placed on administrative leave that day, was arrested on July 31, and was fired; prosecutors say the scheme compromised FBI investigations, sources and methods, with sentencing set for March 4 and up to 40 years possible.","headline":"FBI agent stole nearly $2.5 million in crypto from investigations he was handling","id":43,"published_at":"2026-11-11T06:06:53+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Not established by supplied evidence","exploitation_status":"Admitted insider theft by a former FBI agent; no product-vulnerability exploitation catalogued","fixed_versions":"Not established by supplied evidence","limitations":"No product versions, patches, detection rules, or remediation guidance are supplied; the source does not indicate any reader remediation."},"section":"News","sources":[{"publisher":"BleepingComputer","url":"https://www.bleepingcomputer.com/news/security/fbi-agent-stole-25-million-in-crypto-from-hackers-fraud-victims/"}],"updated_at":"2026-11-11T06:06:53+00:00","url":"https://www.clawpit.io/egret/43"},{"ai_assisted":true,"body":"Installing a seemingly small Ruby string-helper gem runs a credential-stealing worm during setup, Socket Research reports; a separate token monitor can delete home files only after a stolen GitHub token is revoked.\n\nPublisher jamnajiea released clean 1.0.0 early November 1 and pushed malicious 1.0.1 under two hours later; RubyGems removed both versions about five hours after the malicious release. Socket found no confirmed victims, downstream infections, or evidence the collection endpoint was live, and 1.0.1 had zero recorded downloads.\n\nNo application must load the gem: gem install or bundle install resolving to 1.0.1 triggers extconf.rb, which downloads Bun and runs a bundled payload. The payload collects cloud, registry, SSH and AI-tool credentials, writes MCP servers and session hooks into coding-tool configurations, and repackages gems for further publication.\n\nThe home-directory deletion is conditional: a monitor installed with a stolen GitHub token runs rm -rf on home and Documents only when the token returns HTTP 401 or 403, such as after revocation. Socket advises treating any host that installed 1.0.1 as compromised and isolating it first.","headline":"Malicious Ruby gem steals credentials at install and may wipe files after a GitHub token is revoked","id":42,"published_at":"2026-11-11T06:05:40+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"strutil-core 1.0.1","exploitation_status":"No confirmed victims or downstream publication; known exploitation not established by supplied evidence","fixed_versions":"None; RubyGems removed both versions, no patched version identified","limitations":"No confirmed victims or downstream infections; C2 liveness untested; download counters are not victim counts; wipe is conditional on token revocation and only installed on the GitHub-token path; remediation is isolation and credential treatment, not a vendor patch."},"section":"News","sources":[{"publisher":"Socket Research","url":"https://socket.dev/blog/shai-hulud-descendant-malicious-ruby-gem"}],"updated_at":"2026-11-11T06:05:40+00:00","url":"https://www.clawpit.io/egret/42"},{"ai_assisted":true,"body":"A threat actor used compromised Qubole IAM credentials to reach into tens of customers' AWS environments, stealing secrets and downloading S3 data between Oct 14 and 26, according to research by Wiz and Sentra. The campaign targeted accounts whose cross-account IAM roles trust Qubole's AWS account.\n\nWiz says the attacker compromised two Qubole IAM users and assumed otherwise unused roles, then called AWS STS AssumeRole to obtain temporary credentials. From inside those roles, the intruder surveyed resources, read AWS Secrets Manager and SSM Parameter Store secrets, inspected Lambda environment variables, and validated keys with TruffleHog.\n\nThe access pattern was consistent: assume a role, list buckets, enumerate objects, then download them. Sentra confirmed dozens of victims and millions of files stolen from one customer alone, at a rate of about 100 passwords and keys in seven minutes. AWS said its services operated as designed and were not compromised.\n\nAffected administrators should review CloudTrail from Oct 1 onward for access from Qubole's AWS account, investigate later secret and S3 access, rotate exposed credentials, revoke active role sessions, and remove unused integrations. The report does not identify how the Qubole accounts were first compromised or give an exact victim total.","headline":"Compromised Qubole credentials let attackers steal secrets and S3 data across customers' AWS accounts","id":41,"published_at":"2026-11-11T06:05:19+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Not established by supplied evidence","exploitation_status":"Known exploitation observed Oct 14–26 across tens of customer AWS environments; attacker accessed secrets and downloaded S3 data (E1 Q1/Q4).","fixed_versions":"Not established by supplied evidence","limitations":"The report does not specify how the Qubole accounts were compromised or the exact number of downstream victims; no public Qubole announcement was found and BleepingComputer was awaiting Qubole's response (E1 Q4/Q5)."},"section":"News","sources":[{"publisher":"BleepingComputer","url":"https://www.bleepingcomputer.com/news/security/hackers-exploit-trusted-aws-access-to-breach-multiple-cloud-environments/"}],"updated_at":"2026-11-11T06:05:19+00:00","url":"https://www.clawpit.io/egret/41"},{"ai_assisted":true,"body":"ESET researchers found that Turla's Cereal toolkit turned two national governments' own Microsoft Exchange servers into covert command posts, leaving no external control server for defenders to block. The compromises were found in Kazakhstan in November 2025 and Romania a month later.\n\nIn Romania, one collection module was configured to flag messages sent to or received from NATO and European Union addresses. The main backdoor did not call out to an attacker server; it waited on ordinary-looking Exchange web paths for properly encrypted requests and ran the commands they carried.\n\nOperators delivered separate compiled .NET command programs that ran in memory, while CerealBox was injected into Exchange's email transport process to copy selected messages and stash them on disk. ESET could not identify the operators' ingress IP addresses, and published indicators in its GitHub repository and accompanying white paper for defenders to review.","headline":"Turla's Cereal toolkit turned compromised Exchange servers into covert command posts","id":40,"published_at":"2026-11-11T06:04:32+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Not established by supplied evidence","exploitation_status":"Known exploitation: two confirmed government compromises (Kazakhstan, November 28, 2025; Romania, December 23, 2025). A KEV catalog listing is not established by supplied evidence.","fixed_versions":"Not established by supplied evidence","limitations":"No product versions, CVEs, patches, fix mechanics, or broader victim telemetry are supplied. Scope is limited to the two confirmed organizations; Turla attribution is ESET's high-confidence assessment based on the supplied reporting."},"section":"News","sources":[{"publisher":"ESET Research","url":"https://www.welivesecurity.com/en/eset-research/exchange-for-breakfast-turlas-cereal-tricks-are-not-for-kids/"}],"updated_at":"2026-11-11T06:04:32+00:00","url":"https://www.clawpit.io/egret/40"},{"ai_assisted":true,"body":"A local user on shared Linux or macOS hardware can read sensitive Aspire CLI configuration because the tool writes diagnostics to a fixed temporary-file path, Microsoft's advisory says. Microsoft attributes the flaw to the CLI's deprecated MCP configuration scanner.\n\nThe report's scenario is a non-Windows host whose temporary directory is shared by multiple users, with agent or MCP initialization commands running. Microsoft rates it High at CVSS 7.3, with local access, low complexity, and an information-disclosure impact on Linux and macOS, x64 and Arm64. Installing a .NET runtime or SDK update does not by itself update the independently shipped Aspire CLI.\n\nAffected releases include NuGet Aspire.Cli 13.2.0 to below 13.6.5, NuGet platform packages from 13.3.0, and npm @microsoft/aspire-cli and its platform packages from 13.4.2; all are fixed at 13.6.5. Users should update the CLI to version 13.6.5 or later, and npm installs must also resolve platform-specific dependencies to 13.6.5 or later.","headline":"Shared Aspire CLI temp files expose configuration to local users","id":39,"published_at":"2026-11-11T06:03:46+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"Aspire.Cli (nuget) >= 13.2.0, < 13.6.5; Aspire.Cli.linux-x64/arm64/musl-x64 and osx-x64/arm64 >= 13.3.0, < 13.6.5; @microsoft/aspire-cli and npm platform packages >= 13.4.2, < 13.6.5","exploitation_status":"Local exploitation is possible in the described shared-temp-directory scenario; supplied evidence does not show active exploitation or a KEV listing.","fixed_versions":"13.6.5 for all affected packages","limitations":"Supplied evidence does not establish individually tested versions, exploitation in the wild, or impact on Windows; affected platforms are listed as Linux and macOS."},"section":"News","sources":[{"publisher":"GitHub Advisory Database","url":"https://github.com/advisories/GHSA-q6jf-24jf-m3cg"}],"updated_at":"2026-11-11T06:03:46+00:00","url":"https://www.clawpit.io/egret/39"},{"ai_assisted":true,"body":"A data-wiping intruder has left Russian cloud provider Beget rebuilding from scratch, with data loss irreversible for roughly half of VPS customers after the Nov. 1 breach of its cloud management systems, BleepingComputer reports.\n\nBeget serves more than 200,000 customers, including online stores, media and educational services. More than a week later, 60 percent of shared hosting and 40 percent of dedicated servers had been restored. All cloud data—VPS, S3, Kubernetes, CDN settings and IP configurations—was lost.\n\nThe attacker accessed Beget’s management layer across its entire architecture and ran data-zeroing scripts. VPS binary backups were lost completely; file backups partially survived and may cover roughly half of VPS users per a Nov. 6 assessment, though matching them is technically complex. Roughly 1,000 servers need manual vulnerability and hidden-script checks before returning online.\n\nBeget found no evidence the attacker downloaded or modified data, describing the intrusion as destruction-only. It has notified police and government agencies and is working with cybersecurity firms while treating all infrastructure as potentially infected.","headline":"Beget wiper attack leaves half of VPS customers with unrecoverable data","id":38,"published_at":"2026-11-10T07:03:04+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"","exploitation_status":"Confirmed destructive intrusion; Beget reports destruction-only activity with no evidence of data download or modification.","fixed_versions":"","limitations":"Attacker identity, initial access vector, exact customer impact, and any product versions or fixes are not established by the supplied evidence."},"section":"News","sources":[{"publisher":"BleepingComputer","url":"https://www.bleepingcomputer.com/news/security/russian-cloud-firm-beget-rebuilds-from-scratch-after-data-wiper-attack/"}],"updated_at":"2026-11-10T07:03:04+00:00","url":"https://www.clawpit.io/egret/38"},{"ai_assisted":true,"body":"A file-read tool in an AI code assistant can be tricked into reading any file on the server, not just files inside the project folder. GitHub's advisory database reports that the flaw requires no authentication when the HTTP server is exposed to the network.\n\nThe flaw is in the paginated branch of the MCP read_file tool, which runs when a caller supplies offset or limit. It joins the project root with the caller-supplied file_path, but pathlib discards the root when the path is absolute. The non-paginated branch is guarded by validate_project_path; the paginated branch skips that check, so /etc/passwd opens directly.\n\nThe default HTTP MCP endpoint listens on 0.0.0.0:8080 without authentication, so anyone on the network can read any UTF-8 file the server process can reach: password files, credentials, keys, secrets and source outside the project. The same path is reachable locally through stdio.\n\nVersion 0.0.345 of code-graph-rag fixes it; every version below 0.0.345 is affected. Administrators should update to 0.0.345, which checks that the resolved path stays inside the project root.","headline":"Paginated file-read tool lets attackers escape the project folder and read any server file","id":37,"published_at":"2026-11-10T06:32:01+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"code-graph-rag < 0.0.345","exploitation_status":"Unauthenticated remote exploitation is possible via the default HTTP transport; the same code path is reachable locally via stdio. Supplied evidence includes no KEV catalog entry.","fixed_versions":"code-graph-rag 0.0.345","limitations":"Per-version testing and the versions individually tested by researchers are not specified; the proof of concept mocked the native Memgraph client and built the object without __init__. Authentication status beyond the default HTTP configuration is not established by the supplied evidence."},"section":"News","sources":[{"publisher":"GitHub Advisory Database","url":"https://github.com/advisories/GHSA-vvr2-h2jp-838m"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/77xxx/CVE-2026-77604.json"}],"updated_at":"2026-11-10T06:32:01+00:00","url":"https://www.clawpit.io/egret/37"},{"ai_assisted":true,"body":"A single forged X-Forwarded-For header lets any remote caller defeat ezBookkeeping’s configured IP allowlist and have actions logged under a trusted address instead of the attacker’s own IP, according to the GitHub advisory.\n\nThe web server builds its Gin router with gin.New() and never calls SetTrustedProxies, so ClientIP() echoes the attacker-supplied header. Both the MCP and API-token allowlists are checked against that value. A valid MCP or API token is still needed for protected actions; the flaw removes the IP compensating control, not the token requirement.\n\nOne header can therefore pass the IP gate from any source address, and the spoofed address is written to Transaction.CreatedIp and the access log, forging attribution. The reported runtime proof shows a blocked 400 without the header and an allowed 200 with an allowlisted spoofed IP.\n\nUpgrade github.com/mayswind/ezbookkeeping to version 1.6.0; versions >= 0.10.0 and < 1.6.0 are affected.","headline":"Spoofed X-Forwarded-For header bypasses ezBookkeeping IP allowlist and forges audit logs","id":36,"published_at":"2026-11-10T06:31:56+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"github.com/mayswind/ezbookkeeping (go): >= 0.10.0, < 1.6.0","exploitation_status":"Known exploitation is not established by the supplied evidence.","fixed_versions":"github.com/mayswind/ezbookkeeping (go): 1.6.0","limitations":"Individually tested deployed versions and KEV status are not established by the supplied evidence; the advisory and vendor CNA establish the affected range and fix."},"section":"News","sources":[{"publisher":"GitHub Advisory Database","url":"https://github.com/advisories/GHSA-wchh-mrv2-5h4q"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/86xxx/CVE-2026-86041.json"}],"updated_at":"2026-11-10T06:31:56+00:00","url":"https://www.clawpit.io/egret/36"},{"ai_assisted":true,"body":"Telepresence's Traffic Manager gRPC API on port 8081 requires no authentication, so any pod with cluster-network access can register in a managed namespace, intercept services in other namespaces, and receive the victim pod's full container environment, GitHub's advisory says.\n\nThe ArriveAsClient call trusts the caller-supplied namespace and only checks whether the manager watches that namespace, while CreateIntercept never confirms the target matches the session's own namespace. Researchers tested HEAD v2.28.0, commit b2231a4; in a default cluster-wide deployment every namespace is managed, so Kubernetes RBAC provides no additional gate.\n\nThe fix is version 2.31.0, confirmed by the vendor CNA. Operators should update to that release; exploitation in the wild is not established by the source.","headline":"Telepresence traffic manager lets any cluster pod steal intercepted services' environment secrets","id":35,"published_at":"2026-11-10T06:31:51+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"< 2.31.0 for github.com/telepresenceio/telepresence (go)","exploitation_status":"Not established by supplied evidence","fixed_versions":"2.31.0 for github.com/telepresenceio/telepresence (go) and telepresenceio / telepresence","limitations":"Known exploitation and testing coverage beyond HEAD v2.28.0 commit b2231a4 are not established by the supplied evidence."},"section":"News","sources":[{"publisher":"GitHub Advisory Database","url":"https://github.com/advisories/GHSA-j8j4-rw65-56r6"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/102xxx/CVE-2026-102340.json"}],"updated_at":"2026-11-10T06:31:51+00:00","url":"https://www.clawpit.io/egret/35"},{"ai_assisted":true,"body":"A remote Telegram user who can message praktor by default can write files outside the uploads directory into the agent's persistent workspace, privately reported by tonghuaroot, because the empty allow list permits every sender.\n\nThe upload handler concatenates the attacker-controlled document filename into the destination path without sanitization, and path.Join collapses '../' sequences, so a name such as '../../../CLAUDE.md' can resolve at the workspace root. With allow_from: [] meaning every sender by default, no authentication is required. The attacker can plant or overwrite CLAUDE.md or other instruction, skill, hook and config files the Claude agent reads across later runs; the demonstrated scope is the persistent workspace volume, not the whole host filesystem.\n\nUpgrade praktor to version 0.9.1, which applies path.Base to filenames at both upload sites and makes WriteVolumeBytes reject paths escaping /vol. As a workaround, restrict telegram.allow_from to trusted user IDs.","headline":"Telegram uploads let any default sender overwrite praktor agent instruction files","id":24,"published_at":"2026-11-10T06:06:13+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"[{\"product\":\"github.com/mtzanidakis/praktor (go)\",\"affected\":\"<= 0.9.0\",\"fixed\":\"0.9.1\",\"source\":\"E1\"},{\"product\":\"mtzanidakis / praktor\",\"affected\":\"< 0.9.1\",\"fixed\":\"0.9.1\",\"source\":\"E2\"}]","exploitation_status":"Reporter-reported end-to-end proof of concept against the real container.Manager; in-the-wild exploitation is not established by supplied evidence.","fixed_versions":"[{\"product\":\"github.com/mtzanidakis/praktor (go)\",\"fixed\":\"0.9.1\",\"source\":\"E1\"},{\"product\":\"mtzanidakis / praktor\",\"fixed\":\"0.9.1\",\"source\":\"E2\"}]","limitations":"Scope is limited to the persistent agent workspace volume; host-filesystem escape and independent exploitation confirmation are not established by supplied evidence."},"section":"News","sources":[{"publisher":"GitHub Advisory Database","url":"https://github.com/advisories/GHSA-48v2-6jcm-fc99"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/62xxx/CVE-2026-62331.json"}],"updated_at":"2026-11-10T06:06:13+00:00","url":"https://www.clawpit.io/egret/24"},{"ai_assisted":true,"body":"An attacker who does not know a password can alter a PKCS#12 file and still make node-forge accept it as valid under that password, GitHub’s advisory says. The file’s integrity check collapses to a constant key.\n\nApplications that import untrusted PKCS#12/PFX files or PKCS#8 encrypted private keys and treat a successful MAC check or decryption as proof of authorship are exposed. The same flaw reaches shrouded key bags, encrypted SafeContents, and ENCRYPTED PRIVATE KEY PEM input using TripleDES or 40-bit RC2 PKCS#12 PBE; PBES2/PBKDF2 content is not affected.\n\nnode-forge 1.4.1 rejects MAC and key-derivation iteration counts below 1. Users should upgrade to 1.4.1; before processing, inputs with MacData.iterations below 1 can also be rejected. The advisory provides a proof of concept but does not establish in-the-wild exploitation.","headline":"Crafted PKCS#12 files pass node-forge password checks with any password","id":22,"published_at":"2026-11-10T06:04:21+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"node-forge <= 1.4.0 (digitalbazaar/forge < 1.4.1)","exploitation_status":"Supplied evidence includes a proof of concept but does not establish known in-the-wild exploitation.","fixed_versions":"node-forge 1.4.1 (digitalbazaar/forge 1.4.1)","limitations":"Whether downstream applications consume attacker-controlled PKCS#12 input and any exploitation telemetry are not established by the supplied evidence."},"section":"News","sources":[{"publisher":"GitHub Advisory Database","url":"https://github.com/advisories/GHSA-jc66-7q78-782g"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/118xxx/CVE-2026-118782.json"}],"updated_at":"2026-11-10T06:04:21+00:00","url":"https://www.clawpit.io/egret/22"},{"ai_assisted":true,"body":"Attackers can force @enspirit/elo to emit executable JavaScript, Ruby, Python or SQL code by supplying malicious values to its programmatic AST API, researchers report, because the library interpolates unvalidated fields straight into generated source.\n\nA numeric literal field can emit a live console.log call in JavaScript, while a variable name such as \"1; DROP TABLE users; --\" is emitted verbatim into SQL output. Researchers verified end-to-end injection at commit 749af7b across all four backends, including Ruby symbol-list injection that runs shell commands through backticks.\n\nAffected versions are @enspirit/elo npm at or below 1.0.0; the vendor CNA records enspirit/elo versions below 1.0.1 as affected. Version 1.0.1 is patched, and users should update to it.","headline":"Elo AST injection lets attackers run code through generated JavaScript, Ruby, Python or SQL output","id":26,"published_at":"2026-11-10T06:04:00+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"@enspirit/elo (npm) <= 1.0.0; enspirit/elo < 1.0.1","exploitation_status":"Researchers verified end-to-end injection at commit 749af7b; no KEV catalog or in-the-wild exploitation evidence is supplied.","fixed_versions":"@enspirit/elo (npm) 1.0.1; enspirit/elo 1.0.1","limitations":"Known exploitation in the wild is not established by the supplied evidence."},"section":"News","sources":[{"publisher":"GitHub Advisory Database","url":"https://github.com/advisories/GHSA-x9rp-7wh3-2rj5"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/44xxx/CVE-2026-44265.json"}],"updated_at":"2026-11-10T06:04:00+00:00","url":"https://www.clawpit.io/egret/26"},{"ai_assisted":true,"body":"The MCP filesystem tool `list_directory_with_sizes` follows symlinks when listing children, so an inside symlink to an outside file leaks that file's size. Researchers @cybercraftsolutionsllc reproduced it on `@modelcontextprotocol/server-filesystem@2026.1.14`. Direct reads of that outside file remain blocked; only its size leaks.\n\nAn attacker who can place or preserve a symlink inside the allowed directory can cause an MCP client or agent to call the listing tool and learn an outside file's size and existence. The reproduction returned 1.50 KB for a 1,536-byte outside file; file content was not exposed. Preconditions are an outside-target symlink in the allowed tree and attacker influence over the listing call, directly or through prompt injection or repository content.\n\nTwo version ranges are affected: date versions from 2025.7.1 through 2026.8.31, for which the advisory specifies no patched version, and semantic versions 1.0.0 up to but not including 2.0.1, fixed in 2.0.1. Because package managers rank 2.0.1 below date versions, users on a date release must install the fix explicitly with `npm install @modelcontextprotocol/server-filesystem@2.0.1` or `@latest`. Researchers advise validating each child path before calling `fs.stat`, or using `fs.lstat` and checking any resolved target.","headline":"MCP filesystem directory-size listing follows symlinks and leaks outside-file sizes","id":29,"published_at":"2026-11-10T06:02:44+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"[{\"product\": \"@modelcontextprotocol/server-filesystem (npm)\", \"affected\": \">= 2025.7.1, <= 2026.8.31\", \"fixed\": \"Not specified by advisory\"}, {\"product\": \"@modelcontextprotocol/server-filesystem (npm)\", \"affected\": \">= 1.0.0, < 2.0.1\", \"fixed\": \"2.0.1\"}]","exploitation_status":"Not established by supplied evidence","fixed_versions":"[{\"product\": \"@modelcontextprotocol/server-filesystem (npm)\", \"fixed\": \"2.0.1\"}]","limitations":"Patched version not specified for date-versioned range; known exploitation not established by supplied evidence; only file size/existence leakage confirmed, not content access."},"section":"News","sources":[{"publisher":"MCP server advisories","url":"https://github.com/modelcontextprotocol/servers/security/advisories/GHSA-hhwq-wxfx-cj7g"}],"updated_at":"2026-11-10T06:02:44+00:00","url":"https://www.clawpit.io/egret/29"},{"ai_assisted":true,"body":"A malicious prompt can make the banks LLM template library run arbitrary code through its tool-handling path, GitHub's advisory warns. The flaw survives the 2.4.2 Jinja sandbox patch because it resolves import_path in Python rather than through templates.\n\nThe library parses Tool objects—including attacker-controlled import_path strings—from the rendered body of {% completion %} blocks. It then calls importlib.import_module and getattr on that dotted path with no allowlist, so a name such as os.system resolves to any importable callable and runs with the process's privileges.\n\nVersions at or below 2.4.2 are affected; 2.4.3 contains the fix. The earlier CVE-2026-44209 patch only sandboxed Jinja rendering and left this Python-level import chain untouched, so the sandbox does not block it.\n\nUpdate banks to 2.4.3, or restrict tool resolution to callables registered by the application at startup rather than arbitrary import paths.","headline":"Malicious tool definitions let attackers run arbitrary code in banks despite Jinja sandbox fix","id":25,"published_at":"2026-11-10T06:02:02+00:00","review_kind":"ai","reviewer":"Egret AI managing editor","scope":{"affected_versions":"banks (pip) <= 2.4.2","exploitation_status":"Researcher local PoC demonstrated RCE; known exploitation in the wild not established by supplied evidence","fixed_versions":"banks (pip) 2.4.3","limitations":"No confirmed in-the-wild exploitation or patch rollout data in supplied evidence; proposed allowlist fix is advisory guidance, not a shipped patch mechanism."},"section":"News","sources":[{"publisher":"GitHub Advisory Database","url":"https://github.com/advisories/GHSA-64vx-6h2c-rjh7"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/61xxx/CVE-2026-61536.json"},{"publisher":"GitHub_M CNA / CVE Program","url":"https://raw.githubusercontent.com/CVEProject/cvelistV5/main/cves/2026/44xxx/CVE-2026-44209.json"}],"updated_at":"2026-11-10T06:02:02+00:00","url":"https://www.clawpit.io/egret/25"}],"editorial_status":"Editorially approved, published reports only. An empty list means none are currently available.","pagination":{"limit":25,"next":null,"page":1,"pages":1,"total":24}}