Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
Google Cloud VMs on AMD Turin chips need a guest OS patch and a stop-and-start to protect against three CPU side-channel flaws, Google said this week.
The company has already applied mitigations against attacks between VMs, and between VMs and the host. Inside a VM, the flaws may let an attacker with code on the same processor core infer data from other processes or the kernel.
The affected machine series are C4D, N4D, H4D, Z4D,, and G4, including bare-metal instances of C4D and Z4D. Turin is the code name for fifth-generation AMD EPYC processors.
All three flaws are Transient Scheduler Attacks (TSA). Two of them, TSA-SQ (CVE-2024-36350) and TSA-L1 (CVE-2024-36357), were first disclosed on July 8, 2025, for earlier EPYC processors.
AMD now says its Zen 5 processors, which include Turin, are "impacted differently from previously characterized AMD processors." The third flaw, CVE-2026-0004, is new. It may let an attacker who can run code on a system infer data in the processor's L1 data cache.
The Xen Project, which maintains the Xen hypervisor, calls the new flaw TSA-Fill. It also says an earlier statement has been corrected: "AMD had previously said that Zen5 CPUs were not vulnerable to TSA-SQ and TSA-L1."
Google rates the issue Medium. AMD classifies all three as local attacks with high attack complexity that require only low privileges, according to its Zen 5 bulletin and CVE-2026-0004 advisory.
As of today, none of the three is in the KEV catalog of exploited flaws kept by the U.S. Cybersecurity and Infrastructure Security Agency. Neither company reports any exploitation in its bulletins.
VMs: Install your OS vendor's fix when it ships. Starting this week, the company will update the CPU information that VMs report, so a patched guest kernel can turn on its mitigations. After that update reaches a VM, stop and start it. As the company puts it: "Rebooting the guest OS isn't enough."
Bare metal instances: If you run your own OS or hypervisor on a C4D or Z4D bare metal instance, apply your vendor's fixes when they are available.
Hypervisors inside a VM: The same CPU information update applies, so patched guest kernels can turn on their mitigations. Stop and start the VM once the update arrives.
GKE: Updated node images for Turin-based bare metal instances will be made available, and upgrading nodes picks up the CPU information update. As of today, the bulletin does not yet list them as available.
Cloud Run: No action is needed.
Customers on older Rome, Milan, and Genoa processors got the same stop-and-start instruction in an earlier bulletin at the time of the original disclosure on July 8, 2025.
The company lists nothing to do in the meantime for VMs whose OS vendor has not yet shipped a fix. It also does not say how to tell when the CPU information update has reached a VM.
A kernel commit that mitigates TSA on Zen 5, including the new variant, is in the Linux kernel source tree. As of today, Debian has fixed CVE-2026-0004 in its Linux kernel only in its unstable branch. Its security tracker still lists the kernels in bookworm, trixie, and forky as vulnerable.
For Turin servers on your own hardware, AMD says both platform firmware and OS updates are needed to mitigate the flaws fully. The mitigation may affect performance, and administrators should weigh the risk to their own workloads, according to its technical guidance.
The Xen Project has published hypervisor patches in its Xen advisory. It says microcode for all TSA flaws on Zen 5 has been in linux-firmware since September 23.
from The Hacker News https://ift.tt/LiUb7ZS
via IFTTT
N-able on Thursday said it's investigating a new public disclosure containing claims of additional vulnerabilities in on-premise versions of N-central running version 2026.4.1 HF2.
"Based on our initial review, the server issue described depends on a non-default configuration in which the Legacy API is turned on and exposed to the public internet," N-able said in a new advisory. "Legacy API is turned off by default in the product and is not recommended."
The company is urging customers to disable Legacy API immediately, if not already. It also noted that Hosted environments are not affected by this issue.
The incident impacts the following services -
N-central On-premise (Americas)
N-central On-premise (APAC)
N-central On-premise (Europe)
The development comes days after N-able released 2026.4.1.26 to address a number of security flaws disclosed by independent security researcher Sean Bales earlier this week. The vulnerabilities are collectively tracked under the name Able2Shell.
The new shortcoming, also revealed by Bales, have been codenamed 4EverAble2Shell and Agent2Shell, adding the proof-of-concept (PoC) exploits successfully work against N-central 2026.4 Hotfix 2 (build 2026.4.1.26), the update N-able released on November 10, 2026, to resolve Able2Shell.
According to the researcher, 4EverAble2Shell enables unauthenticated remote code execution with root privileges on N-central servers. Agent2Shell, on the other hand, leverages more than 10 zero-day vulnerabilities to run commands on managed Windows agents as NT AUTHORITY\SYSTEM, assuming the attacker knows the target appliance ID.
Ryan Dewhurst, founder and CEO of Presidian, told The Hacker News that targeted N-central probing has been observed against 4EverAble2Shell within hours following the release of the PoC. The activity has originated from the IP address 157.20.241[.]16. There is no evidence of successful exploitation as of writing.
In the attack chain observed by the threat intelligence company, threat actors have been observed attempting initial code execution through a recently disclosed Apache Axis flaw (CVE-2026-90436, CVSS score: 9.8) and then attempting to escalate to root privileges using 4EverAble2Shell and then download and execute a shell script from 157.20.241[.]16 using curl.
Dewhurst said the development marks the first documented instance of exploitation attempts aimed at CVE-2026-90436, patches for which were released on November 6, 2026.
In a post shared on X, watchTowr also said it's seeing probes for 4EverAble2Shell targeting N-Centrals builds with the Legacy API enabled.
(This is a developing story. Please check back for more information.)
from The Hacker News https://ift.tt/hCIuzpW
via IFTTT
Since mid-August 2026, a phishing operation has been stealing live Google sessions from corporate users. Every check defenders normally lean on to judge a link came back clean, and the operator designed it that way on purpose.
The Threat Research team at Material Security spotted the campaign and has since taken down hundreds of attacker domains in an effort the team calls Operation CloudFire. Here’s what the researchers found.
The lure: Google Calendar invites
The messages show up as Google Calendar invites. Some arrive by BCC, and many come from an organization the recipient has already traded email with. The pretexts are deliberately boring: voicemail notifications, RFP and RFI requests, court summonses, and missed payment notices. Nothing about them stands out in a busy inbox.
Most of the links point to Google itself. The usual pattern runs through Google’s own /url redirector, with the real destination tucked into a query parameter. Other waves used share.google and Drive file links the same way, and one variant leaned on Intuit transaction notification links. Whenever a message gets scored, the domain, certificate, and reputation on display are all legitimate.
The capture: a reverse proxy in front of Google sign-in
Once a victim clicks through, the attacker runs a live reverse proxy in front of the real Google sign-in page. The victim types a password, gets a genuine prompt, and approves it while the operator watches in real time. The server passes each second factor along to Google as it comes in, whether that’s an SMS code, an authenticator code, Google’s Tap-Yes number matching, or phone-based account recovery. None of those controls stop the session from being captured.
The framework behind it, known as Nyasher, has been publicly documented since February, after researchers found a hardcoded key in its JavaScript.
Why the usual controls stay quiet
Reputation systems answer questions about ownership. They ask who registered a domain, what else it has hosted, and whether anyone has complained about it. This campaign was built so every one of those answers came back harmless.
It works in three layers. The first is Google’s redirector, which gives the initial hop a trusted Google URL. The second is a Cloudflare Turnstile challenge, and in some builds it’s the real widget served from Cloudflare’s own infrastructure. The third is the password capture page, and that’s where things get tricky for defenders. There’s no static site to scan. JavaScript builds the page in the browser after the visitor clears the challenge, so a crawler has nothing to fetch and a proxy log has nothing to record. As far as the researchers know, nobody had scanned those pages before the campaign was documented.
The infrastructure is also meant to be thrown away. Early waves used many lure domains spread across several registrars, and most were registered just days before use. Receiving endpoints went live one to twenty days ahead of the wave they served. One wildcard certificate was issued 46 minutes before the domain it covers was even registered. Blocking any single piece costs the operator a few dollars and an afternoon.
What stopping it took
Researchers tracked the campaign from the start, following each variant as lures, gates, and endpoints rotated. Once detections were in place, they caught more than 99% of the malicious messages, with a reclassification rate of 0.01%. It’s been steady work, since the attacker kept changing tactics, themes, and lure text to slip past static, machine learning, and agentic detections.
What worked was refusing to let any one signal make the call. Reputation alone wouldn’t have caught this. Neither would link analysis, since the first hop is a Google URL and the final page doesn’t exist until a browser builds it. Instead, the detection approach weighs technical indicators alongside the apparent intent of the message, where its links actually end up, and the sending relationship behind it. Any one of those can be enough to act on. A detection built around a single signal inherits that signal’s blind spots, and this operator has put real effort into mapping them.
Where the analysis happens matters too. Gateways built to inspect mail in transit aren’t a great fit for calendar invites, and much of this campaign arrives as invites. Calendar invites need to be treated as a threat surface of their own, with the account’s full history used as context next to the technical signals.
Where the damage lands
A hijacked session leaves its trail in Google Workspace audit logs. A live session reaches mail, Drive, and the ability to grant OAuth access in the victim’s name, so the blast radius goes well past the inbox.
That raises a couple of hard questions for security teams. Who’s actually reviewing those audit logs, and how fast can they act on what they find? Could the team revoke sessions, contain OAuth grants, and reset the affected account within an hour? Plenty of programs can’t, and an attacker holding a live session can do a lot in an hour.
Operation CloudFire: going after the infrastructure
By late September, the researchers decided that tuning rules, retraining models, and updating agents wouldn’t solve this alone. Detection protects customers, but it does nothing about an operator who’s already prepping the next wave. So the team went after the infrastructure.
Analysts pulled the gateway and backend URLs as messages were being sent and reported them through Cloudflare’s abuse reporting system. Cloudflare’s abuse team confirmed the fake interstitial and the proxied Google sign-in page behind it, then put its own phishing warning in front of those destinations.
That had two effects. First, the attacker’s infrastructure got burned. Every reported gateway and endpoint had to be re-registered, re-pointed, and re-certified before the operator could send again. Second, it protected people well beyond any one company’s customers. Anyone who clicked a reported link saw a warning page instead of a credential form.
One month by the numbers
These figures only cover organizations that agreed to share data, so the real totals are higher. Over one month of Operation CloudFire, researchers recorded:
68,676 campaign messages blocked
2,112 unique malicious URLs analyzed
897 unique domains taken down
8,570 unique compromised sender addresses across 6,354 root domains
The messages also followed a clear rhythm, with sends tracking US business hours.
Message delivery by time of day
The sender count explains how the campaign earned trust. The attacker controlled each compromised account before the first invite went out, and each one sent invites to the account owner’s saved contacts, among others. Recipients saw a name or domain they knew, on a domain with a clean history, at a sensible time of day. Reputation feeds had no reason to flag any of it.
Where things stand now
The phishing themes have moved from calendar invites to Google Drive file and document share invites. Researchers haven’t seen a matching jump in other lures or tactics, and activity from this group seems to have scattered. For now, the campaign looks finished.
Messages detected by week
Domains registered by interval
That’s a snapshot, and it could change fast. Rebuilding the infrastructure is cheap, and the framework has been public since February. The operator also shipped an unfinished Microsoft 365 branch alongside the live Google code. It includes a stylesheet path, a second harness, and a title string that decodes to a Microsoft sign-in prompt. None of those paths resolve today, and adding the new brand would only mean dropping in a file, with no code changes. The follow-on is built and waiting.
The researchers see the theme rotation as ongoing iteration and expect the next pivot to look a lot like this one, just with a different brand on it.
The full technical breakdown, including indicators of compromise and a timeline, is in the companion whitepaper. Teams hunting for this activity in their own environments should start there.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/QtXgosw
via IFTTT
PTC has released patches for a new critical vulnerability impacting Windchill and FlexPLM software that, if successfully exploited, could result in remote code execution.
The security flaw, tracked as CVE-2026-126325, carries a CVSS v4 score of 9.2 out of a maximum of 10.0.
It has been described as a case of improper input validation and deserialization of untrusted data that could result in remote code execution via crafted requests.
"A critical remote code execution (RCE) vulnerability has been reported in PTC Windchill and PTC FlexPLM," according to a description of the flaw on CVE.org. "The vulnerability may be exploited through the deserialization of untrusted data."
The CVE record lists the following versions as affected -
"If your Windchill or FlexPLM environment is hosted by PTC, the patches have been applied on their behalf. No action is required on your part," PTC said in a statement posted on its website.
"If your Windchill or FlexPLM environment is not hosted by PTC, we urge you to apply the patch as soon as possible to help protect your systems."
The disclosure comes nearly five months after another critical remote code execution (RCE) issue in Windchill and FlexPLM (CVE-2026-12569, CVSS score: 9.3) came under active exploitation.
Then, in July 2026, it emerged that threat actors linked to the Cl0p ransomware operation were weaponizing the flaw as part of a data extortion campaign designed to drop JSP web shells and exfiltrate sensitive product data from manufacturing companies and industrial enterprises.
"PTC software is a textbook target for initial access brokers and ransomware operators and a significant enabler of triple extortion campaigns," Yordan Ganchev, principal threat intelligence specialist at watchTowr, said in a statement shared with The Hacker News.
"It allows malicious actors to reach far and wide within victim networks, encrypt and exfiltrate proprietary data, and disrupt industrial processes. In many cases, the impact across these environments has downstream implications for time-sensitive manufacturing, logistics, and fulfillment processes, resulting in material costs per hour of downtime."
Organizations running PTC Windchill and FlexPLM products are recommended to patch exposed systems as soon as possible and monitor for signs of code execution, backdoor access, or web shells on the host. If patching is not an immediate option, it's essential to apply network restrictions to limit the risk of compromise.
from The Hacker News https://ift.tt/O3VGrNZ
via IFTTT
A critical flaw in MongoDB Server allows an unauthenticated attacker to send two requests that trigger a crash on the database server. The crash occurs only if that server is later chosen to take over as the main server while it still lacks some recent changes.
MongoDB, the company that makes the database, released fixed versions earlier this week.
The affected servers are members of a replica set, a group of MongoDB servers that keep copies of the same data. One member, the primary, serves as the main server and handles all new writes, while the others replicate them. If the primary becomes unavailable, the other members hold an election to pick a new primary.
Researchers at Datadog Security Labs reproduced the crash in a lab and published their findings yesterday. On vulnerable versions, turning on authentication does not stop the two requests. An attacker cannot make the targeted member fall behind or win an election, or see when either happens, the researchers said.
The flaw, tracked as CVE-2026-118383, is a use-after-free: the server ends up using memory it has already freed. MongoDB rated it 9.5 out of 10 on the CVSS 4.0 severity scale. The company said it found the flaw itself and was "not aware of any attempts to take advantage of this vulnerability."
Affected members include the shard and config server members of sharded clusters. A standalone mongod, a single server outside any replica set, is not affected.
Each affected branch has a fixed release, listed below and in the CVE record. Every earlier version in a branch is affected, back to the branch's first release.
MongoDB Atlas clusters automatically receive fixed versions during maintenance, the company said in its security announcement. Customers who defer maintenance should apply the upgrade as soon as possible.
Self-managed deployments need the fixed release on every replica set member. After upgrading, check the version each member is running, including members in containers and any that were offline during maintenance.
The 8.2 branch is not among the affected versions listed, and its newest release is 8.2.12. But a proof of concept published on GitHub reports that 8.2.12 still exhibited the bug in a lab test using a test-only setting.
The 8.2 branch reached end of life on July 31, according to the company's lifecycle schedule. Past that date, a version no longer receives fixes, including security fixes.
Until a member can be upgraded, the researchers advise restricting network access to the database to only the systems that need it. That limits who can send the two requests but does not fix the flaw.
A member who wins an election first catches up by applying the writes it missed before it accepts new ones. The flaw is in the cleanup that runs when this catch-up step ends, according to the Datadog researchers' technical analysis.
The two requests are ping commands that carry a readConcern.afterOpTime value. Each asks the server to wait until replication reaches a certain point, and the server records a pending notification for it, called a waiter.
Planting the waiters does not crash the server. They do not expire, and stay in place until the member restarts, rolls back or steps down from primary.
The crash needs the member who received the requests to win a later election, even though it is behind another member. When catch-up ends, the cleanup runs twice, reusing memory that was already freed, and the new primary crashes before it accepts any writes. Once those conditions are met, the crash does not depend on winning a timing race, the researchers said.
In the lab, the researchers caused the member to fall behind and forced a failover themselves by using admin access to pause and stop mongod processes. Only the two requests came from a client without credentials, and that client could not write to the database.
On version 8.0.34, the member crashed with a segmentation fault, leaving the lab cluster without a primary. Another deployment might elect a new primary and keep running.
In the fixed version 8.0.37, the server rejected both requests as unauthorized at once, and the member kept running. One part of the fix lets only system users use readConcern.afterOpTime.
MongoDB says the flaw may also result in arbitrary code execution in the server process under certain conditions. In the lab, though, "we did not achieve code execution," the researchers said. Their results also do not show how often the attack would work in other setups.
The proof-of-concept code reproduces the bug in a lab replica set, according to its author. Its reliable mode requires a test-only setting that a remote attacker cannot enable. Its stated impact is a crash or memory corruption, with no claim of code execution.
The second part of the fix stops the cleanup from running twice even when waiters are already in place, the researchers said. They did not test that part themselves.
In the proof-of-concept lab test, which ran with authentication turned off, the fixed 8.0.37 accepted the planted waiters but ran the cleanup only once.
To look for planting or a crash, check the server's structured logs for these signs from the researchers' vulnerable run:
Log event: a COMMAND "Slow query" entry (ID 51803) for an unauthenticated ping carrying readConcern.afterOpTime that ended with MaxTimeMSExpired.
Log event: a member entering primary catch-up (ID 21359), then exiting it twice (ID 21363) in one transition.
Log event: a fatal signal or backtrace involving CatchupState::abort_inlock() after those exits.
A normal election or a single catch-up exit does not point to this flaw. The requests may also arrive before the failover, so check earlier logs from the same member too.
Whether the request fields are logged depends on logging settings, and the attr.remote field may show a loopback address instead of the client's real IP.
from The Hacker News https://ift.tt/jb15X4Q
via IFTTT
A flaw fixed in Node.js this week lets unauthenticated clients crash servers that use the runtime's built-in HTTP/2 support on the 24.x and 26.x release lines. A second HTTP/2 flaw can cause a server to send a client pieces of its memory, including responses intended for other connections.
Fixed versions were released for all three supported lines: 22.23.5, 24.22.3, and 26.13.1.
The crash flaw, CVE-2026-123863, needs only a default HTTP/2 server that replies before the request body has fully arrived. The Node.js project calls that behavior typical. The crash works over both TLS and cleartext connections.
The memory flaw, CVE-2026-123866, affects all three lines. From 24.22.0 and 26.9.0 onward, a client alone can trigger it. On 22.x and older 24.x and 26.x builds, it can still be triggered when the server itself closes a stream partway through a response, for example after an idle timeout.
A separate flaw in Node.js HTTPS servers, CVE-2026-123864, can allow an unauthenticated client to read memory from other connections, "including TLS private keys and other users' requests," the project says. It affects all three supported lines.
The flaw needs a handler that calls res.flushHeaders() before the request body has fully arrived and later calls res.end() with data. Reading the leaked memory also needs a route that sends back or stores a request body. Plain HTTP servers built with node:http are not affected.
The release fixes 16 vulnerabilities in Node.js itself, seven of them rated high. The other four high-rated flaws, and the servers they affect, are:
CVE-2026-123865: a client can make any default HTTP/2 server hold memory and file descriptors permanently, on all three lines.
CVE-2026-123874: a client can corrupt server memory on 24.x and 26.x when the server serves files with stream.respondWithFile() or stream.respondWithFD(). On all three lines, canceling such downloads can also crash the server (CVE-2026-123875, rated medium).
CVE-2026-126051: a client can crash a TLS server on 24.x and 26.x if the server uses the SNICallback, OCSPRequest, newSession or resumeSession hooks, or server.addContext().
CVE-2026-123872: on a TLS server with stricter client-certificate rules for some hostnames, a client approved for another hostname can switch to a stricter one during TLS 1.2 renegotiation without meeting its rules. All three lines are affected.
The eight flaws above are all in Node.js's own HTTP/2, HTTPS and TLS server code, so they matter where a Node.js process accepts those connections itself.
Updating to the fixed version for each line is the only fix in the project's security advisory. It lists no workaround for servers that cannot update yet.
End-of-life lines, including 20.x and 25.x, get no fix in this release, and the project says such versions are always affected.
The advisory does not report any attacks using the flaws. It also does not say whether servers that met the conditions for the HTTPS flaw should replace their TLS keys or other secrets after updating.
Five of the flaws, including CVE-2026-123863 and CVE-2026-123864, were reported by Chris Rohlf in collaboration with Claude and Anthropic Research, according to the advisory.
from The Hacker News https://ift.tt/zApXTbl
via IFTTT
Starting Tuesday, an attacker used stolen credentials for 4,837 GitHub accounts to plant a secret stealer in repositories those accounts could write to, according to Aikido Security, a security software company.
The stealer is built to take the secrets and cloud credentials that a repository's CI workflows can reach. It ran in at least 1,806 repositories, where the attacker has likely collected those credentials, the company says.
Each attack started with a pull request titled docs: dependency audit notes, opened from a branch named wfx-docs to test whether the account could write to the repository. These test pull requests were pushed to 61,764 repositories, and the stealer followed in some of them.
After pushing the stealer, the attacker reverted the change within a minute and usually deleted the workflow run and its logs. Where the stealer ran, every secret and cloud role available to the repository's workflows should be treated as compromised.
More pull requests with the same title were opened early today, after the company's own GitHub search ended on Wednesday, a check by The Hacker News found. Three that were checked, opened between 05:04 and 05:38 UTC, came from wfx-docs branches. It is not clear whether the stealer followed.
Any account that opened one of the attacker's test pull requests is compromised, even if the stealer never ran, Aikido said in its technical analysis. The analysis does not explain how the attacker obtained the credentials and offers no advice for the owners of the stolen accounts.
In most other repositories that received a test, nothing was pushed afterward, or the stealer did not run due to the repository's settings or the account's permissions. The figures cover only the public repositories the company could see.
The tests also reached repositories that the compromised accounts did not own. Of the test pull requests, 10,431 were submitted via collaborator or organization access, and 92% of those were still open when the company checked.
Signs a Repository Was Hit
The company lists these signs to check for, from Tuesday onward, in any repository you can write to:
Branch:wfx-docs
Branch:chore/[a-z0-9]{8}, short-lived
Branch:ci-check-[0-9]{4}
Pull request title:docs: dependency audit notes
Commit message:ci: refresh build cache, which adds about 1,500 lines to an existing workflow
Commit message:chore: add ci helper, which adds a .ci-xxxxxx.sh script and a postinstall hook in package.json that runs it on any npm install
Commit message:chore: add dependency audit workflow, which adds .github/workflows/build-audit-xxxxxx.yml on a chore/ branch
A repository can show no wfx-loot artifacts, wfx- cache entries, or WFX-BEGIN step summaries and still have lost data. In this campaign, the stealer was set to send data only by HTTP POST to the two addresses above.
A missing run number on the attacker's commit is the more reliable sign that the stealer ran.
The stealer is built to collect credentials from every source on the runner, according to the company. They include GitHub Actions secrets and variables, the workflow's GITHUB_TOKEN, OIDC and Actions runtime tokens, keys for AI services, and secrets in the memory of the runner's own processes. It reads credential files for AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH, and other tools from their usual locations.
It also copies the repository, its last 100 commits, and recent workflow artifacts. On self-hosted runners, it takes cloud credentials from instance metadata as well as Docker container state and systemd units.
The stealer also has settings for private repositories, and the company says that suggests it may be running in them.
The stealer is designed to use those credentials to access deeper within cloud accounts. It exchanges GitHub OIDC tokens for AWS, GCP, and Azure sessions, and on AWS it can create long-lived access keys for IAM users.
Some of its steps are built to survive credential rotation. It can rewrite an AWS role's trust policy to open the role to any AWS account.
It can also add federated identity credentials with the prefix wfx-ci- to Azure AD applications. Workflows in the compromised repository can then sign in to Azure without a stored secret, even after all tokens are rotated.
The stealer reached at least one Packagist package and one Go module through automated publishing triggers. At least 50 of the compromised users appear to publish packages for npm, Go, Packagist, PyPI, or crates.
The attacker appears to be after CI secrets rather than trying to spread through packages, the company says.
Version 3.14.3 of the Packagist package digitalelvis/neuronai-studio is malicious, and any machine that installed or opened it should be treated as compromised. Its package listing shows the version was published on Wednesday. Early today, the version was still listed, under a notice that versions of the package had been flagged as malware.
Two versions of the Go module github.com/onuragtas/docker-env, v1.0.278 and v1.0.280, carry the stealer only in a GitHub Actions workflow file. The Go code and release binaries are unchanged, and Go builds never run workflow files, so users of the module may not have been affected. The company still recommends removing those versions.
The accounts used this week overlap with those hit in GhostAction's October wave, in which stolen GitHub accounts pushed secret-stealing workflows into repositories.
Accounts hit in October were about 1,000 times more likely than other active accounts to be used this week. In more than 100 repositories, the new stealer was added to October's workflow files, leaving the older step that sends data out in place.
Aikido said, "we don't attribute November to the same actor at this stage," because the infrastructure, tools, and methods differ, and stolen credentials often end up with several attackers.
from The Hacker News https://ift.tt/nHjW4ty
via IFTTT
Microsoft observed multiple incidents in which threat actors deployed GSocket, an open source remote access tool, on compromised Linux servers. Threat actors used Gsocket to maintain access even after the vulnerabilities used for initial compromise were remediated. This turned a single web application compromise into persistent access that outlasted the remediation of the original vulnerabilities. Defenders investigating affected hosts should look for evidence of GSocket deployment, persistence, privilege escalation, and outbound connections, rather than treating application patching alone as complete remediation.
Microsoft Defender for Endpoint telemetry shows this activity growing over recent months and concentrated on web applications and hosting environments. GSocket relays traffic through a shared public network, so there is no threat actor-owned IP address or domain to block.
When one RCE stops being just one RCE
Exploiting a web application vulnerability gives a threat actor command execution in the context of the web server process. That access lasts only while the vulnerability remains unpatched and the service keeps running. Patching the application or restarting the service can remove it.
To keep access, threat actors typically add a persistence mechanism, and each common option has drawbacks. SSH keys added to authorized_keys are easy for administrators to find during an audit. Reverse shells depend on threat actor-controlled servers that defenders can block or sinkhole. Custom implants require ongoing development and maintenance. The same trade-offs apply when initial access comes through remote access services or cloud shell sessions.
GSocket addresses these drawbacks, which helps explain why multiple unrelated threat actors have adopted it.
Shared relay infrastructure. Traffic passes through the Global Socket Relay Network, a public relay service. The threat actor does not register or host any infrastructure, so there is no threat actor-owned IP address or domain to block. Organizations can still restrict access to the relay itself.
Outbound-only connections. The compromised host and the operator both connect outbound to the relay, which bridges the two sessions. The host needs no inbound listener or public IP address, and network address translation does not prevent the connection. Inbound firewall rules do not see this traffic, although egress filtering and outbound monitoring can.
Built-in evasion and persistence. The deployment script can rename the process, stage files in memory-backed directories, and install persistence that survives a reboot, without additional development by the threat actor.
The same relay model that supports legitimate remote administration also gives threat actors a way to maintain access without operating dedicated C2 infrastructure. Once GSocket runs on a compromised server, the server and the operator each connect outbound to the Global Socket Relay Network, which pairs the two sessions over an end-to-end encrypted channel.
Figure 1: After code execution on an internet-facing application, GSocket is deployed and both ends connect outward to the relay.
Because GSocket runs independently of the exploited application, patching the vulnerability does not remove the relay client or its persistence.
Microsoft Defender for Endpoint telemetry shows that this activity is not limited to a single compromise. From March through August 2026, devices with GSocket-related detections increased 356.2%, although the increase was not consistent month to month.
Figure 2: Growth in GSocket-related detections from March to August, measured against the March baseline.
Web applications and hosting accounted for 87.1% of attributable Microsoft Defender for Endpoint incidents in the analysed telemetry. Within that group, PHP web applications and cPanel hosting represented 63.9% of incidents and Apache represented 24.3% (Figure 3).
Figure 3: Distribution of GSocket-related incidents by application category. PHP web applications and Apache account for most incidents within the web applications and hosting group.
Education and research accounted for the largest share of affected organizations (30.7%), followed by technology and telecommunications (22.9%).
Figure 4: Distribution of affected organizations by sector.
These figures reflect the share of affected organizations and do not indicate that threat actors selected these sectors deliberately. Exposure is the more likely factor: academic institutions often run large, decentralized web estates maintained outside central IT, which are harder to inventory and patch.
Observed attack chains
The RCE-based intrusions in this analysis followed a similar sequence after initial access. Threat actors compromised an internet-facing application, profiled the host, transferred and concealed the relay tooling, and used the resulting channel for command and control. Some intrusions also included persistence and privilege escalation. Figure 5 combines these behaviours into a generalized attack chain. Not every stage occurred in every intrusion.
Figure 5: Generalized GSocket attack chain observed across RCE-based intrusions, mapped to MITRE ATT&CK.
How threat actors deploy and operate GSocket
Initial access and deployment: Threat actors exploited internet-facing web applications and used curl to download and execute a remote script. The script profiled the host, selected a GSocket client matching the system architecture, staged it in writable or memory-backed paths such as /dev/shm, and established encrypted outbound command and control through the Global Socket Relay Network.
Figure 6: Encoded RCE command executed through a vulnerable PHP application.
Defense evasion and persistence: Threat actors disguised GSocket with kernel-thread-like process names, persisted through cron, systemd, shell profiles, watchdogs, and redundant copies, then removed staging files and other deployment indicators.
Figure 7: Kernel thread names used to disguise the GSocket process.Figure 8: Persistence entries created during GSocket deployment.
Privilege escalation: After gaining execution as the web-service account, in few observed incidents, threat actors attempted to exploit CVE-2026-43284, one of the recent Linux kernel vulnerabilities also known as Dirty Frag, to elevate privileges to root.
How GSocket reconnects without a fixed C2 address
GSocket identifies endpoints by a shared secret instead of an IP address or hostname. During installation, the deployment script typically generates a random secret and writes it to standard output. The threat actor can choose to read the secret from the console, redirect it to a temporary file and retrieve the file before is deleted, or have it delivered through a supported notification channel, such as Telegram (configured with GS_TG_TOKEN and GS_TG_CHATID), Discord, or a webhook. With this secret, the operator can reconnect later from any compatible GSocket client, without knowing the victim’s IP address, hostname, or network location.
A traditional reverse shell connects to a threat actor-controlled IP address written into the payload. GSocket instead derives its connection identifier and authentication material from the shared secret. The compromised host and the operator each connect outbound to the Global Socket Relay Network (GSRN), which matches them and brokers an end-to-end encrypted session. Neither endpoint needs a public IP address, an inbound listener, or a permissive inbound firewall rule.
As a result, blocking an IP address or domain is unlikely to cut off access. The connection relies on a shared relay service, outbound traffic that is commonly permitted, and a secret that does not need to be hardcoded in the payload. Anyone with the shared secret can reconnect through the relay without knowing the compromised host’s IP address or hostname.
Mitigation and protection guidance
For an affected Linux server, remediation should address both the initial compromise and the GSocket deployment.
Patch and harden internet-facing applications. Keep web applications, CMS platforms, plugins, and application servers current. Remove unused components and restrict file-upload and administrative paths.
Remediate the host as well as the vulnerability. Do not treat application patching as complete remediation. Investigate and remove the GSocket client, associated persistence, and staged files, then verify that outbound connections to the relay infrastructure have stopped
Patch and harden internet-facing applications. Keep web applications, CMS platforms, plugins, and application servers current. Remove unused components and restrict file-upload and administrative paths.
Constrain outbound traffic. Apply deny-by-default egress rules, allow only required destinations, and monitor connections to relay infrastructure.
Harden the host runtime. Mount temporary and memory-backed directories as non-executable where feasible, and alert on execution from hidden or world-writable paths.
Audit persistence surfaces. Review cron entries, systemd units with plausible service names, and shell startup files. Persistence is often layered across several mechanisms, so stopping the running process alone does not remove access.
Prioritize local privilege-escalation patching on internet-facing servers. In the analyzed activity, threat actors attempted to exploit CVE-2026-43284 to escalate from the web-service account to root. Separately, Microsoft FORGE Lab recently documented 59 Linux kernel bug reports, including eight vulnerabilities for which researchers demonstrated local root privilege-escalation exploits in controlled environments.
Enable Microsoft Defender for Endpoint on Linux. Keep real-time and cloud-delivered protection enabled, with behavior monitoring for anomalous child processes of web services and masqueraded process identities.
Microsoft Defender detections
Microsoft Defender for Endpoint provides visibility into activity associated with GSocket-related Linux intrusions, including suspicious shell execution, payload delivery, persistence, defense evasion, and remote communication. The alerts below were observed in the analyzed telemetry. An individual alert does not establish the initial access method or confirm that every stage of an intrusion succeeded.
Tactic
Observed activity
Example alerts observed in analyzed telemetry
Initial access, Execution
Shells and commands launched from web servers and application runtimes
– Possible Web Server compromise activity – Suspicious shell execution from PHP application – Suspicious shell execution from web server application – Suspicious shell execution from a scripting application runtime – Suspicious remote command execution via Java Web application – Suspicious remote command execution through Node web application
Execution
GSocket and gs-netcat tooling launched on the host
– ‘GsNetcat’ hacktool was prevented – ‘GsNetcat’ hacktool was blocked and was active – An active ‘GsNetcat’ hacktool was blocked – An active ‘GsNetcat’ hacktool process was detected while executing and terminated
Execution, Payload delivery
Shell commands and scripts used to retrieve, prepare, and launch payloads
– Suspicious shell command execution – Suspicious piped command launched – Suspicious script launched – Executable permission added to file or directory – Suspicious file dropped and launched – Suspicious file or content ingress
Persistence
Cron jobs and Linux services created for recurring execution and continued access
– Suspicious cron job creation – Suspicious Linux service created
Defense evasion
Hidden file execution, obfuscation, timestomping and removal of binaries or history traces.
– Hidden file executed – Suspicious file or information obfuscation detected – Suspicious deletion of launched process binary – Attempt to clear command history – Suspicious timestamp modification
Discovery
Reconnaissance and collection of local system information
– Reconnaissance activity – Suspicious process collected data from local system
Command and control
Reverse-shell behavior and communication with GSocket domains
– Possible reverse shell – Suspicious communication with a remote target
Microsoft Security Copilot
Security Copilot customers can use the standalone experience to create their own prompts or run prebuilt promptbooks to automate incident response or investigation tasks related to this threat:
Incident investigation: correlate web-service process ancestry, relay client deployment, persistence changes, and outbound activity into a single timeline for the affected host.
Threat actor profile: summarize observed GSocket tradecraft and related tooling seen in the environment.
Device summary: assess the affected Linux host, its exposed application, and follow-on activity after initial execution.
Advanced hunting queries
Microsoft Defender XDR customers can use the following queries to surface GSocket-related activity. The queries use public Advanced Hunting tables populated by Microsoft Defender for Endpoint and cover deployment patterns observed in the analyzed intrusions.
Matches should be investigated in context with process ancestry, execution context, persistence changes, and related network activity.
GSocket process activity
Looks for GSocket tooling by name or command line.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName has_any ("gs-netcat", "gsocket")
or ProcessCommandLine has_any ("gsocket.io", "gs-netcat", "gsnetcat")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath,
ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc
Installer download activity
Looks for the download-and-execute pattern used to fetch GSocket.
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has "gsocket.io"
or ProcessCommandLine has "gsgg.b-cdn.net"
| project Timestamp, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName
| order by Timestamp desc
Connections to observed distribution hosts
These are tool distribution endpoints, not threat actor-owned command and control.
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has_any ("gsocket.io", "gsgg.b-cdn.net")
| project Timestamp, DeviceName, ActionType, RemoteUrl, RemoteIP, RemotePort,
InitiatingProcessFileName, InitiatingProcessAccountName
| order by Timestamp desc
Known file hashes
Matches the SHA-256 hashes published in the indicators of compromise section.
let badSHA256 = dynamic([
"d94f75a70b5cabaf786ac57177ed841732e62bdcc9a29e06e5b41d9be567bcfa",
"f95c4d029e6784e3849b4d1e2e2ae1a661187236ef7c5d487c71158a290a03b5",
"55d141bb2f62c527c3fea3413b8429fed7d52633d0b123b5e611bfa42165229f",
"12450bafc7a4398040e1ad3a16dbf4dbc79b6a8f83ef306c4f0f73f59886f06c"
]);
DeviceFileEvents
| where Timestamp > ago(7d)
| where SHA256 in~ (badSHA256)
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
Staging and persistence artifacts
Useful when hashes are missing or a different build is used.
DeviceFileEvents
| where Timestamp > ago(7d)
| where FolderPath startswith "/dev/shm/.gs-"
or FileName in~ ("systemd-remount-d", ".gsn_ora", "defunct", "defunct.service")
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc
MITRE ATT&CK techniques observed
The following techniques were observed across the analyzed intrusions. Not every technique occurred in every intrusion, and some outcomes, such as persistence across reboot and successful relay session establishment, were not confirmed in every case.
Initial access
T1190 Exploit Public-Facing Application | Internet-facing web applications were exploited to gain command execution in the web service context. Follow-on commands were launched as children of web server and application runtime processes, consistent with exploitation of an exposed application.
T1053.003 Scheduled Task/Job: Cron | Cron entries were created in the same detection window as GSocket deployment script activity, consistent with persistence.
T1036 Masquerading | A GsNetcat binary executed as systemd-remount-d, a system service-like filename. In a separate execution context, bash used exec -a to present /usr/bin/defunct with the argument-zero name [kaluad].
T1105 Ingress Tool Transfer | curl downloaded gs-netcat payloads from GSocket distribution endpoints into /dev/shm/.gs-0.
T1090.002 Proxy: External Proxy | GSocket clients were launched with options that establish outbound sessions to the Global Socket Relay Network, a shared public relay that brokers the connection between the compromised host and the operator. The relay is third-party infrastructure and is not owned by the threat actor.
Indicators of compromise
The indicators below were observed in the analyzed telemetry. They represent specific observations from these intrusions rather than a complete inventory of GSocket tooling or infrastructure.
Indicator
Type
Description
gsocket[.]io
Domain
Script and installer retrieval
cdn[.]gsocket[.]io
Domain
Client binary distribution
gsgg[.]b-cdn[.]net
Domain
Client binary distribution
hxxps://gsocket[.]io/y
URL
Script retrieval in download-and-execute commands
hxxps://gsocket[.]io/install.sh
URL
Installer retrieval target; successful retrieval not established
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
At Microsoft’s FORGE Lab, we used codename MDASH to scan a subset of Linux kernel subsystems from late May to mid-June 2026. One full-time researcher and one intern led this three-month effort, which has so far produced 59 public upstream reports and 33 assigned CVEs. We confirmed working root privilege-escalation exploits for eight of those CVEs, and fixes for 38 of our reports have been merged into mainline.
Finding the bugs was only part of the work. The initial scans produced 26,502 raw findings in about two weeks, but turning those results into reproducible bugs, upstream reports, and patches took months of expert investigation and collaboration with Linux maintainers.
In this post, we look back at how we went from thousands of potential findings to validated vulnerabilities and upstream fixes, and what we learned about scaling vulnerability discovery with AI.
From scans to reports
We focused on several core kernel subsystems, such as networking, filesystems, and security modules. Our selection criteria were straightforward: we picked security-sensitive components with no obvious dependence on specialized hardware, making QEMU-based validation simple and unified. Code scanning mainly used Sonnet 4.6 (71.1% of code-scanning tokens), GPT-5.4 (20.1%), and GPT-5.5 (7.1%).
The codename MDASH scans produced 26,502 raw scan findings in about two weeks on two servers (64 cores/256 GB RAM and 32 cores/128 GB RAM), but turning that output into patches and reports took months of expert work. We filtered out low-confidence claims using codename MDASH’s confidence levels and separate fast screening agents we built, reducing the pool to 11,769 candidates. PoC-generating agents then attempted reproduction in QEMU, mainly using GPT-5.5 (77.3% of reproduction tokens), Opus 4.6 (13.2%), and GPT-5.5-cyber (9.4%). Experts then reviewed the 621 cases with PoC evidence to identify root causes, merge duplicates, and prepare upstream submissions.
Roughly one public upstream report landed from every ten PoC-backed cases: 59 reports from 621 cases (9.5%). Across those cases, the main reasons for not filing a separate new report were:
266 (42.8%) shared a root cause with another case, so one patch could fix them together.
163 (26.2%) were not reported after review, mostly due to limited security impact.
133 (21.4%) were already reported or fixed upstream.
Submission timing explains many of the 133 overlaps. Most of the 621 cases were new when the scans finished (though some may already have been in flight by others). Our first public report went out on June 27, 2026, more than five weeks after scanning started. By September 1, 55 of the 59 had been posted to the public lists; the other four were reported privately during the same window and routed to the public lists by mid-October.
Getting fixes merged
Upstream Linux typically requires vulnerability reports to come with a working patch. Agents helped draft initial fixes, but human validation, subsystem understanding, and iterating with maintainers during review remained essential. So far, fixes for 38 of our reports have been merged into upstream mainline—half on the first submission, and the rest after one to four revisions. Reaching a mainline release from the first public patch took a median of 41 days (up to 108 days), and we are still working with maintainers on the remaining reports.
How old the bugs were
Interestingly, most of the bugs we reported had been in the kernel for years. Across the 59 reports, the average bug was 8.1 years old when we first reported it publicly. One of the oldest, a cls_u32 shift-out-of-bounds bug (CVE-2026-74544), had been there for at least 21 years.
Figure 2 . Age of reported kernel bugs, measured from the bug-introducing commit (the fix’s Fixes tag) to our first public report. Average age 8.1 years across 59 reports; six were 15–19 years old and three were at least 20 years old.
Selected findings
Among the 33 CVEs assigned so far from this batch, 24 are rated High or above (CVSS v3.1 score of at least 7.0). Below are eight CVEs for which we confirmed local root privilege-escalation exploits in controlled laboratory environments, with some cases requiring non-default settings or disabled exploit mitigations:
CVE-2026-64563 is a one-line state-reset bug in rhashtable, the Linux kernel’s shared resizable hash table. Because callers trust the object pointers returned by a table walk, this small library flaw enabled a stable local privilege escalation on Linux—and affected Android with SELinux enforcing—without requiring special kernel configurations or user namespaces.
Many kernel subsystems store live objects, such as sockets, in rhashtable and walk the table when user space asks to list them. Because a large listing may be split across several replies, a walk can pause and resume. Its iterator saves where it stopped, including a pointer to the last visited entry (iter->p). While the walk is paused, however, the table can still change: entries can be removed and freed, and resizing can replace the underlying bucket table.
Old table freed by a resize (iter->walker.tbl == NULL): lines 877–882 switch to the new table, reset slot and skip, and return -EAGAIN early without clearing iter->p:
Old table still present (iter->walker.tbl != NULL): lines 884–919 scan the bucket chain for iter->p and reset iter->p = NULL if the entry was removed.
After that restart, the next call to rhashtable_walk_next() sees iter->p still set and follows iter->p->next instead of starting over at slot = 0. If that entry was freed while the walk was paused, dereferencing iter->p->next reads from freed memory.
Why did this bug go unnoticed for eight years? Triggering it requires three conditions to line up in the same walk: the caller must pause and resume the same iterator across walk_stop() and walk_start(), a table resize must free the old bucket table during that pause, and the entry at iter->p must also be removed and freed before the walk resumes. Most rhashtable walkers finish in a single pass without ever resuming a stopped iterator, and even when a caller does pause and resume, those three events rarely coincide by accident in normal workloads.
The upstream fix simply clears the stale pointer before returning:
+ iter->p = NULL;
From a socket listing to a kernel write
Because rhashtable is a shared library, its callers determine both whether this bug is reachable and how severe its security impact can be. Across the kernel, there are about two dozen files that use the rhashtable walker API, and most walk the table in a single pass and immediately exit. Among those callers, we found two that pause and resume an iterator across batches and can at least cause a crash: TIPC’s socket dump (tipc_nl_sk_walk()) and Netlink’s socket diagnostics (__netlink_diag_dump()).
Of the two, __netlink_diag_dump() is the exploitable caller. It is reachable by unprivileged users on standard kernels, and user space controls the pause between dump replies (via recvmsg()). An attacker can hold a dump paused while resizing the table and freeing the socket at iter->p, then reallocate that memory to control iter->p->next—causing rhashtable_walk_next() to return a fake socket pointer sk.
__netlink_diag_dump() then checks net_eq(sock_net(sk), net) and passes sk to sk_diag_fill() and sock_diag_save_cookie(), which initializes sk->sk_cookie if it is zero. That turns the fake sk pointer into a constrained 64-bit write (when the target 8 bytes are zero and sk->sk_net matches &init_net). Paired with other general exploitation techniques, this write is enough for local privilege escalation.
We thank Yuan Tan of NebuSec, who also independently found this vulnerability. He promptly shared its real severity with us and the maintainers, which helped the upstream fix, and later provided us with his working exploits for both Linux and Android. We also thank Frank Wu of NebuSec, who identified a viable exploitation primitive and developed a working privilege-escalation exploit.
Closing thoughts
Finding bugs and fixing them are drastically out of balance. Two weeks of codename MDASH scanning produced the initial findings, which we narrowed to 621 PoC-backed cases. But it took over four person-months to report 59 of them—and five months later, 38 fixes have been merged. For complex infrastructure like the Linux kernel, keeping humans in the loop is still necessary, making human effort the bottleneck. Both bug hunters and maintainers can be overwhelmed by the volume of real findings, so focusing on genuinely high-severity issues is essential.
More tokens may yield more bugs, but not a secure system. We scanned only a small fraction of the kernel, and further tuning and more tokens could uncover substantially more bugs. But even after fixing all of them, is the system secure? At Microsoft FORGE Lab, we’re using AI to expand the scope of vulnerability research, but our experience shows that discovery is only one part of the work. The more urgent problem is how to build practical security solutions that are operational, cumulative, and economically sensible.
These lessons also extend beyond our research. Through close collaboration with the engineering teams building codename MDASH, we’re applying what we learn from real-world vulnerability discovery and validation to inform how these capabilities evolve. The goal is to bring advances in AI-powered security research into the hands of security teams, helping them identify and address critical vulnerabilities more effectively.
