Attackers Hijack Dahua IP Cameras in Ukraine Using P2P Access and Auth Weaknesses

The Computer Emergency Response Team of Ukraine (CERT-UA) has issued an alert warning of unauthorized remote access to video surveillance systems manufactured by Dahua.

"Cases of compromising IP cameras and DVRs with access to the video stream, changing the device configuration and creating third-party accounts have been recorded," the State Special Communications Service of Ukraine (SSSCIP) said in an alert issued last week.

The primary initial access vector used in the attacks is via Easy4IP, a peer-to-peer (P2P) platform that allows users to remotely monitor homes or small businesses by connecting their Dahua IP cameras, NVRs, and DVRs via a smartphone app or web browser by scanning a QR code or entering the hardware Serial Number (SN).

The agency has warned that the serial numbers have a predictable structure containing a 10-character model prefix that's identical for all units of the same device family and a five-character hexadecimal counter that's incremented almost sequentially (e.g., 7K01F36PCA003E8).

This, in turn, allows attackers to guess them at scale through a brute-force attack and identify if they are connected to the cloud without hitting rate limits or lockouts. As a result, all devices with active P2P functionality are at risk even if they cannot be accessed directly via the internet.

"The assumption that the serial number is unknown to anyone is not a reason to consider the device secure," CERT-UA said.

Authentication barriers are overcome by leveraging weak or known passwords, or by exploiting authentication bypass vulnerabilities in outdated firmware versions, such as CVE-2021-33044 and CVE-2021-33045. CERT-UA has shared the following indicators of compromise associated with the activity -

• Presence of unknown accounts
• Unauthorized configuration changes
• Audit logs containing authentication events using the manufacturer's native protocol (DVRIP) and from a local address (127.0.0.1), a sign of P2P access.

To counter the threat, it's advised to disable the P2P feature if not required, avoid exposing them directly to the internet, and keep the software up-to-date.

The agency has not disclosed who was targeted, when these infections occurred, how many devices had been infected, or who was responsible for the activity. However, the findings share similarities with two clusters of activity that Hunt.io disclosed as targeting IP cameras in Ukraine and Russia.

One of the campaigns, attributed to a Russian-speaking operator, singled out internet-exposed cameras in Ukraine using known Dahua and Hikvision vulnerabilities, ultimately compromising 58 devices. The activity involved the exploitation of the following flaws by integrating Ingram, a publicly available webcam vulnerability scanner -

• CVE-2017-7921 - An authentication bypass vulnerability in Hikvision
• CVE-2020-25078 - A credential disclosure vulnerability in D-Link
• CVE-2020-25169 - An unauthenticated information disclosure vulnerability in Reolink
• CVE-2021-33044 / CVE-2021-33045 - Authentication bypass vulnerabilities in Dahua that allow passwordless login
• CVE-2021-36260 - An unauthenticated remote code execution vulnerability in Hikvision.

In parallel, the threat actor is also said to have undertaken scanning and exploitation of TP-Link and MikroTik routers and cameras using vulnerabilities like CVE-2024-53375 and CVE-2024-57049 across 15 European countries, including Ukraine, Poland, Romania, Moldova, Hungary, Czechia, Slovakia, Bulgaria, Germany, France, the Netherlands, Italy, Spain, the U.K., and Austria.

The second campaign, codenamed Operation CameraSwarm and attributed to a lone threat actor, is believed to have compromised over 14,530 Dahua IP cameras between June 17 and July 22, 2026, using a combination of credential brute-force attacks and the exploitation of the CVE-2021-33044-CVE-2021-33045 chain.

The attack scans for TCP port 37777, which is the default proprietary management and video streaming port used by Dahua, followed by collecting serial numbers, breaking into those devices by employing the aforementioned two exploitation methods, and then deploying a persistent backdoor account ("p2pwn / p2password") on nearly 2,000 cameras in a manner that can survive password change and a factory reset.

"1,923 cameras carry a persistent backdoor account (p2pwn / p2password), installed over RPC after either bypass," Hunt.io noted at the time. "It is stored independently of the admin password and survives a password change and, on most firmware, a factory reset. 283 cameras were reached by serial number alone through Dahua's cloud relay, with no device address and, in most cases, no credentials."

In some instances, the attackers have been found to abuse Dahua's cloud relay to reach cameras behind NATs using only their serial numbers.

Earlier this year, Dutch intelligence agencies warned that Russian actors are compromising IP cameras across the E.U., NATO states, and Ukraine to conduct systematic digital espionage operations and acquire military intelligence.

"This actor performs automated analysis of imagery through image recognition software to conduct targeted searches for military vehicles and the military cargo they are transporting," the July 2026 bulletin said.

"This provides the actor with, among other things, relevant military data, such as E.U. and NATO military transport routes, weapon deliveries to Ukraine, and the locations of Ukrainian military personnel. The information from IP cameras in Ukraine is used in attempts to neutralize Ukrainian military personnel and to destroy their military material."

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/2rfAisv
via IFTTT

CISA Confirms Active Exploitation of Two PHP2Shell Flaws Enabling Remote Code Execution

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday confirmed active exploitation of the recently patched PHP2Shell flaws by adding them to its Known Exploited Vulnerabilities (KEV) catalog.

The PHP vulnerabilities, both rated 9.2 on the CVSS scoring system, facilitate unauthenticated remote code execution on affected deployments -

• CVE-2026-109618 - An out-of-memory corruption vulnerability that allows for unauthenticated remote code execution.
• CVE-2026-109619 - A stale internal request-state vulnerability that allows for unauthenticated remote code execution.

The addition of the two flaws to the KEV catalog comes after Adel Karimi, detection and response lead at Perplexity, confirmed successful instances of remote code execution against honeypot systems on October 24, 2026.

"This is now confirmed RCE with usable memory disclosure, not just a crash followed by a suspicious process," Karimi said. "The response delivered an 800 KiB decoded cookie dump, and a function address derived from that dump using the public exploit's offsets appears in the subsequent execution payload."

"The evidence demonstrates this chain on the intentionally favorable single-worker mod_php profile; it is not a measurement of exploit reliability on other worker counts, PHP builds, or applications."

The issues have been addressed in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 released on October 21, 2026. Federal agencies have time until October 29, 2026, to apply the necessary fixes.

PHP, short for PHP: Hypertext Preprocessor, is a server-side scripting language used in roughly 70% of all websites on the internet. According to estimates shared by Censys, more than 32.51 million PHP services are still running an affected version.

The severity of the vulnerabilities has prompted numerous advisories from software and security vendors and government agencies across the world, including -

As of October 26, 2026, the PHP Foundation also released Windows builds 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1 to address CVE-2026-111497, an out-of-bounds write vulnerability in the Brotli decoder library that could also result in privilege escalation and unauthenticated remote code execution.

The vulnerability, also known as Broccoli2Shell, HTTP2Shell, and Node2Shell, affects Brotli versions 1.0.3 through 1.0.9, 1.1.0, and 1.2.0. It has been patched in versions 1.0.10, 1.1.1, and 1.2.1, along with other projects that include the C library, including Node.js, Bun, Envoy Proxy, Istio, .NET, and Python.

"In PHP Windows builds, the vulnerable decoder can be reached through the cURL extension when automatic HTTP response decompression is enabled," the PHP Foundation said. "This is disabled by default in cURL, but applications and HTTP client libraries can enable it."

from The Hacker News https://ift.tt/5HzWiYp
via IFTTT

Hackers Infect 953 Online Stores With Scanner-Evading JavaScript, Mostly on Magento

An unknown threat actor has infected 953 online stores, most of them running Magento, as part of a long-running campaign active since July 2025.

According to Dutch e-commerce security company Sansec, the activity is designed to add a small piece of code to the store's pages that, when visited by unsuspecting users, serves malicious JavaScript loader code through Magento CMS blocks.

"When you visit, that code makes your browser ask the group's server what to do next," Sansec said. "The server first checks whether you are a real shopper or a security scanner, so scanners get nothing."

No less than five distinct domains have been observed over time in connection with the campaign -

• manulfie[.]click, first seen in July 2025
• neswnsssn[.]click, first seen in December 2025
• lanhd6549tdhse[.]top, first seen in March 2026
• additionalver[.]com, first seen in June 2026
• deepveindrilling[.]com, first seen in October 2026

Sansec said it found deepveindrilling[.]com in the CMS blocks of 83 online stores since the domain was registered on October 6, 2026.

The latest JavaScript loader domain is hosted behind Cloudflare and only responds to script requests from real visitors of infected stores. The loader is staged within Magento's cms_block database table, which is used to render static content into storefront pages.

The ultimate objective of the attack is to launch the attack-controlled code when the CMS block is rendered after a shopper opens the compromised website.

While Sansec does not disclose whether the threat actor modifies an existing CMS block (such as header, footer, or promotional banner) or creates a new block, the attacker can adopt either of the approaches to run the loader.

Two different versions of the loader have been spotted. In one version, the external JavaScript loaded from the attacker's domain stores the payload in the browser's localStorage. This causes the stashed code to be run again on subsequent visits, even if the external domain becomes unavailable.

The second version expands on this behavior by incorporating browser fingerprinting checks to filter out bots and security scanners, while ensuring that only real shoppers are exposed to the malicious code. The exact nature of the final payload remains unknown.

Early iterations of the campaign have also been observed using Keitaro, an advertising tracker and analytics platform, as a traffic distribution system (TDS), to route visitors to different responses – i.e., return a payload, a redirect or nothing – based on their characteristics.

Sansec said requesting the additionalver[.]com script as a Windows desktop visitor returned as response "QWE=123;," which does nothing apart from setting a cookie that marks the visitor for 24 hours. The deepveindrilling[.]com domain, on the other hand, drops the Keitaro component and integrates the bot-filtering logic into the loader itself.

As for the initial access vector, 471 Magento stores are estimated to have been injected with the loader through the PolyShell (aka CVE-2026-48356) vulnerability. Another 102 stores saw files uploaded through the PolyShell or SessionReaper (aka CVE-2025-54236) vulnerabilities.

"One store on Magento 2.4.7-p1 had PolyShell webshells disguised as PNG images in pub/media/custom_options/quote/, next to the additionalver.com loader in a CMS block," Sansec said. "The block switched to deepveindrilling[.]com on October 7. The store still lacks APSB26-73, Adobe's PolyShell fix for supported release lines."

In another case, an e-commerce store running Magento 2.4.7-p10 with no missing core patches was compromised to add a rogue administrator account and then use it to inject the code.

Site owners are advised to audit their sites for suspicious accounts and unexpected CMS blocks in the cms_block and cms_page tables. It's also advised to keep the sites up-to-date and enforce strong passwords.

The disclosure comes against the backdrop of PHP2Shell, a set of two critical vulnerabilities in PHP (CVE-2026-109618 and CVE-2026-109619) that have witnessed widespread exploitation attempts following their disclosure last week.

However, Perplexity researcher Adel Karimi has recorded what appears to be the first in-the-wild successful exploitation of the vulnerabilities to run shell commands on honeypot servers. These commands have been observed using wget, curl, or PHP CLI to fetch additional payloads from a remote server ("162.35.99[.]94:80").No downloaded second-stage artifacts have been observed so far.

from The Hacker News https://ift.tt/OjC0Mh3
via IFTTT

Between alerts: What Attackers Do in the Spaces Ordinary Detection Misses

Every SOC struggles with a pile of alerts. Very few of those alerts explain how an attack started or how it progressed. Network data, like that from a network detection and response (NDR) platform, connects individual alerts into one timeline, and it feeds the defensive systems that can tie all events together into one coordinated view.

SOC teams often first see the shape of an intrusion through a series of smaller alerts that are triggered (e.g., when a signature matches a known malware hash, a threshold flags an unusual spike in failed logins, or an endpoint agent detects suspicious activity). When viewed through the SIEM dashboard, an attack often begins as a series of distinct events with related or overlapping timestamps.

Artificial intelligence has accelerated modern attacks, enabling attackers to automate reconnaissance, craft targeted payloads, and execute scripts in seconds. Yet, speed does not obfuscate the need for stealth. To evade detection, adversaries deliberately draw out operations, hide inside standard admin tooling, and work in the quiet intervals between alarms.

Adversaries might spend days or weeks inside an enterprise environment before an action generates a high-priority security alert. When an alert finally surfaces, it doesn’t necessarily mark the start of a compromise. It may, in fact, be one event in a much longer sequence. Analysts who investigate only the triggering event may miss the chained activity that explains how the intrusion developed.

The anatomy of silent progression

Between initial access and a high-severity alert, adversary activity can blend into ordinary business operations. Adversaries understand the operational limits of security teams, and they exploit them; if every DNS query, LDAP request, SMB connection, or authentication attempt generated an investigation, SOC queues would quickly become (even more) unmanageable.

Tradecraft purposely takes advantage of that reality.

Adversaries can spread reconnaissance across hours or distributed sources. Instead of launching an obvious scan, they may use a compromised account to query a domain controller over LDAP at a modest pace to map users, groups, and systems. A handful of Kerberos service ticket requests can yield credentials to crack offline, well outside the SOC’s view. Valid credentials then open the door to SMB or RDP, the same services administrators rely on every day, and the attacker moves from host to host. Files may be gathered on one internal system and compressed. Later, that system may reach an external destination over HTTPS or DNS at regular intervals, with just enough variation in timing to resemble normal traffic as it exfiltrates data.

Each step borrows something the business already depends on.

While individual actions may not necessarily look suspicious, their significance often emerges from relationships and sequences. For instance, a host that communicates with a new system once may be unremarkable. A host that queries several internal services, authenticates to a peer, establishes an SMB session, and then connects to an external destination presents a different investigative picture. The activity becomes more meaningful when viewed across time.

When siloed tools see only slices of this type of transaction, they might miss the bigger picture. Context only becomes readily apparent when activities and signals are combined and correlated via network observation.

What’s more, attackers increasingly use AI to automate reconnaissance and move faster. Defenders need to apply AI to the same problem, but it needs detailed network evidence from an NDR to search.

The evidence between the alerts

SecOps teams don’t have to turn detection thresholds down and drown analysts in more alerts just to spot adversary activity. Doing so would be untenable anyway. A SOC can’t investigate every DNS query, authentication request, or connection as though it were an incident. In addition, many teams operate with tools that show an alert fired yet offer sparse detail on how the activity behind it unfolded.

To prevent blindspots, SOC teams can retain the underlying network telemetry so an analyst can go back and review what happened when an alert, outage, or other signal gives them a reason to look.

However, that requires more than knowing when two systems exchanged traffic. Protocol-aware network data from an NDR platform can show the kind of interaction that took place, who or what participated, when it happened, and how that relationship evolved over time.

For instance, if a workstation triggers an endpoint alert at 2:14 p.m. the alert may show an analyst what happened on the endpoint at that moment. Network evidence from an NDR can extend the timeline and answer a few crucial questions:

• Was the workstation querying an unusual domain earlier that day?
• Did it authenticate to another system or establish SMB connections to internal peers?
• Did those systems communicate with additional hosts?
• Did the workstation later establish an encrypted session with an external destination?

Each individual event may have perfectly legitimate explanations. It’s only in combination, though, that the sequence provides a different level of context.

For an investigator, that context helps establish whether the endpoint event was an isolated problem or one discrete stage in a broader progression. For an AI-assisted investigation, the context derived from NDR provides the evidence needed to search for related activity across hosts, users, protocols, and time rather than treating each alert as a separate event.

Why this matters for the AI SOC

AI in the SOC changes the economics of an investigation. While a human analyst has to decide which systems, users, sessions, and time periods deserve attention, an AI-assisted SOC can search across that same breadth of evidence much faster, bringing relevant data into one view in minutes rather than hours. Correlation and analysis can happen asynchronously, allowing analysts to review and query a broader set of data much sooner. When AI handles the synthesis, the process of identifying patterns is faster, still.

When an attacker is patient, methodically timing actions across longer periods, evidence might be spread across hundreds of seemingly ordinary transactions. Since a human analyst can’t reasonably manually investigate each piece of evidence, the more practical approach is to construct an automated workflow in an NDR platform to identify context and look for relationships, then give the analyst the evidence so they can make a judgement call.

The outcome is more activity examined, across more systems, over a longer period. The benefits are:

• Time savings: manual work is significantly reduced
• Clearer insights: more context can be surfaced by advanced algorithms searching across thousands of data points
• Better decisions: analysts can focus on making strategic risk decisions instead of picking apart pieces of alerts

The same process can help with operational issues. If an application goes down, for example, network telemetry will show which services were communicating, where communications began to fail, which dependencies were affected, and what changed around the event. If the cause turns out to be malicious, the investigation already has a record of the activity.

Beyond individual alerts

Alerts give analysts a place to start an investigation. They do not necessarily explain what happened before it, what happened after it, what’s happening simultaneously, or whether other activity in the environment is related. Issues that appear routine in isolation may look very different when data is correlated and context is added.

Network telemetry provides the surrounding evidence needed to build critical context. Protocol-aware data from the NDR preserves the details of network interactions, including both ends of a communication, the protocols and services involved, timestamps for those interactions, and how interactions change over time. It’s the telemetry that gives automated investigation workflows a broader body of evidence to work from when triaging a high-priority alert.

With evidence available for automated analysis, AI agents can correlate activity over time, connect communications between systems, and surface sequences that would otherwise remain separate innocuous-looking events. The ability to apply context across disparate communications and sequences is what allows SOC teams to find the riskiest activity. Without this evidence, individual alerts and sequences may continue to present as harmless. Attackers have already identified the opportunity; now it’s time for defenders to apply the same principles and keep up.

About Corelight:

Your AI SOC is only as effective as the data behind it. Corelight network detection and response (NDR) delivers data that’s open, transparent, and explainable—helping detect evasive threats, reduce triage time, and enable agentic AI throughout the SOC. Corelight’s structured network evidence preserves protocol-level context to produce a more complete dataset for investigation and AI. When analysts and AI can reason from evidence instead of isolated alerts or metadata, they can validate findings, reconstruct activity, and reach more reliable conclusions. Learn more about Corelight at https://corelight.com/cp/elitedefense

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/VBeW8ZS
via IFTTT

uCreator Android Spyware Can Steal Telegram 2FA Passwords and Clone WeChat Accounts

A rentable Android spyware kit called uCreator takes over Telegram and WeChat accounts by hiding its code inside working copies of the two apps, researcher Ovi found. It only reaches people who install one of these tampered copies, spread outside the official app stores, or who run WeChat inside the kit makers' own container app.

The kit's Telegram part matches Baohuo, a backdoor that Doctor Web reported in October 2025. Doctor Web found Baohuo in tampered copies of Telegram X, an Android app from Telegram. At the time, the company estimated that more than 58,000 devices were infected.

The Hacker News compared the two reports. Doctor Web's technical description of Baohuo lists the same code namespace, com.ucreator.tgjar, the same command-and-control (C2) server, and matching command names as Ovi's analysis.

Ovi's analysis, published October 21, 2026, does not mention Doctor Web's findings, and Doctor Web did not name the kit. It is not clear whether the kit's makers or one of their customers ran the campaign Doctor Web tracked.

Who Is Exposed

The tampered apps spread through sideloading, where a person installs an app file directly instead of from an app store, and through social engineering, Ovi found. He could not confirm how every victim was infected.

A second route is the kit makers' own container app, called 洋葱盒子 ("Onion Box"), which runs other apps inside itself.

Some of the tampered Telegram X copies use the same package name as the real app on Google Play, so the name alone does not give them away.

Doctor Web found that Baohuo copies had been spreading since mid-2024 through in-app ads that led to fake app store sites. Those sites promoted Telegram X as a dating and video chat app.

The sites' banners were available only in Portuguese, for users in Brazil, and in Indonesian. Even so, Doctor Web's 2025 map of infected devices by country put India first, at 22.8%, ahead of Brazil at 20.5% and Indonesia at 9.6%.

Baohuo copies also turned up in the third-party stores APKPure, ApkSum and AndroidP. On APKPure, one was listed under the official developer's name, although its digital signature was different.

Ovi got access to one of the kit's command servers. It held data on victims apparently located in China and the United States, but not enough for a reliable count. He calls his report "an analysis of technical capability, not a measurement of victim impact."

The apparent targets, still unconfirmed, are users of mobile wallets and messaging apps in China and Southeast Asia, including WeCom, QQ, WhatsApp, LINE, Zalo, KakaoTalk, Viber, GCash and MoMo. He found code supporting about 20 apps, but has published code only for Telegram and WeChat.

The kit's hooking engine is the part that lets its code intercept an app's functions. Ovi checked it on a Pixel 10 Pro running Android 17. It could not find an internal Android function it relies on, because newer Android versions changed that function.

Another tool, Frida, could still hook apps the same way on that phone. Ovi therefore describes this as extra work for the kit's makers, not proof that Android 17 blocks the attack.

The newest sample, dated July 29, 2026, still carried the old engine. He recovered samples built for Android 16 but did not report testing that version. He has not tested phones from Chinese makers.

How It Takes Over a Telegram Account

Inside a tampered Telegram app, the kit's code starts with the app and runs with the app's own identity and permissions, Ovi found. That gives it the same access as the signed-in app.

Each tampered app also runs a local command server inside itself. The code for each target app is downloaded after installation, which makes the installer file harder to analyze on its own.

Attackers can send any database query to the app's message store and get chat history back.

Telegram's two-step verification (2FA) password is entered in the app, which uses it to generate a login proof on the phone. The kit hooks that step and copies the password in readable form before the app hashes it.

With the password, the code can reset the account's logged-in sessions, change the linked phone number, or delete the account. Other parts of the code are designed to lock out the owner while keeping the attacker's session alive.

The code can also hide the attacker's session from the device list that the tampered app shows the user.

Doctor Web's description of Baohuo covers the same device-hiding. The backdoor also sends the account's phone number, name and password to its server every three minutes.

Neither Ovi nor Doctor Web says whether a hidden session still appears on the user's other, untampered Telegram apps. Neither gives steps for securing an account taken over this way.

Ovi says the code shows what the kit can do, not that attackers have used every step from start to finish.

Earlier Android malware has also run legitimate apps with attacker code inside them. FjordPhantom did this to banking apps through virtualization in 2023, and so did the GodFather banking trojan in 2025.

Ovi argues the kit is different because it is sold as a product. Customers can steer it remotely against any app its makers write a module for.

The WeChat Part and the Leaked Back End

For WeChat, the kit can also use app virtualization, running the unchanged app inside its own container, Ovi found. A command copies out the account's login identity. The app's data is then zipped and uploaded, and a bundled login script is used to clone the account.

This part goes after the account itself, not its chat history.

Ovi and another researcher, Jurre, also found the back-end code behind the kit on a self-hosted GitLab server. It was the one part of the setup not limited to approved IP addresses.

The code shows a cloud console that merchants and resellers rent. Every command carries the customer's ID, so each customer aims its own share of the phone fleet at victims it picks.

Commands go to phones in the kit's phone farm, a set of phones the operation controls, and to victims' phones. There, the kit captures login authorizations, adds friends in bulk, collects contact and profile data, and backs up whole accounts.

A scheduler sets time windows, random daily limits, and per-account budgets, so the activity looks human and gets past the platforms' risk checks. The code calls this "account cultivation," in Ovi's translation.

About three dozen developers, all working on China time, appear in the code's history, and some were still adding changes in October 2026.

The leaked back end covers personal WeChat and WeCom accounts. Ovi says it did not appear to cover Telegram, and only one of several GitLab servers was exposed.

Who Is Behind It

Ovi ties parts of the operation to three companies in Hunan province, China. One is linked to the kit's brand website and a server certificate, another to a government website filing for a command server, and the third to the signature on the kit's Windows control program.

He says a shared owner is "plausible, but remains unproven."

The makers' own name for the product is YingGai, and the product line appears in records dating back to September 2021. The samples Ovi studied date from 2024 to July 2026.

Ovi assumes the kit is used for financially motivated crime, given its focus on wallets and one-time passcodes. Doctor Web described Baohuo as "a tool for boosting the number of subscribers in Telegram channels."

Indicators of Compromise

The kit leaves two traces on a phone that Ovi calls reliable. One is a code file, TgJarPine.dex, in the assets of some tampered Telegram copies. The other is the original app copy that LSPatch, an off-the-shelf patching tool, leaves at cache/lspatch/origin/*.apk.

Because that second trace comes from LSPatch itself, it can also appear in apps patched with the tool for other reasons.

When The Hacker News checked DNS records on October 23, 2026, several of the kit's server and download domains no longer resolved. The domain for its version-upload server still pointed to 121.37.194[.]194.

The kit's indicators include:

• SHA-256: 2fc4bad71eda25b9022ea7cb090d6419911ecd67e50e746b418f8a617a980301 (com.ucreator.tg, framework and command handlers)
• SHA-256: 0142749a159be3e41d28f910eebf28b577a282880bd0c2383bd7404189f4ff94 (com.uckj.tgx, loader)
• SHA-256: dcec9640271a782553599197bcb85367971a5bb4aa84c3787d1e49a3f4f9420e (org.thunderdog.challegram, tampered Telegram X, November 2024)
• SHA-256: 805834e6b8c12e180117a1816b48e387c33b53520f5a91cbf858441dc895e717 (org.telegram.messenger.web, tampered Telegram, July 2024)
• SHA-256: a90e3ab2b5cf306439a378faf7107a89196116ad7ee4ad5791c2ba8839ba21c4 (org.thunderdog.challegram, tampered Telegram X)
• SHA-256: f82ac2c525d1ed82e57b3f27ae689aeda46875a893ca4c42876b3166ba66bb20 (com.ucreator.va_vx, WeChat host)
• SHA-256: 99c5be579d218acfd2c7e2662528e7ad32a1a605d8efd1da732c13931bc30c4c (com.ucreator.va_yjb_client, Onion Box)
• SHA-256: 9c8b147f76312e651faabb1411a3270efca984dd8f33bd8ded3ea611c7c583a1 (uip.exe, Windows control program)
• Domain: hpncallback.gold5play[.]com (command server, not resolving on October 23)
• Domain: hpncallback.qianxunlbs[.]com (command server, not resolving on October 23)
• Domain: telegram-apk.uzyzx[.]com (download host, not resolving on October 23)
• Domain: hw.android.videoflow[.]cn (version uploads, pointing to 121.37.194[.]194 on October 23)
• IP: 159.138.237[.]10:32115 (Redis server)
• IP: 159.138.229[.]12:26379 (Redis server)
• Domain: r-bp1jehsclgbuu48m7tpd.redis.rds.aliyuncs[.]com:65531 (Redis server, WeChat part)
• IP: 43.225.141[.]209 (relay used by the Telegram part)
• URL: kfpt.oss-cn-hangzhou.aliyuncs[.]com/android/app/YingGai/ (hook downloads)

Doctor Web has published its own indicators for Baohuo.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

from The Hacker News https://ift.tt/xvdasHV
via IFTTT

Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs

An automated campaign is using stolen GitHub tokens to plant workflows that print a repository's secrets into its GitHub Actions logs, which the attackers then download before deleting the runs. The attacks have succeeded in private repositories and GitHub Enterprise environments, according to an analysis by cloud security company Wiz.

A GitHub safeguard that pauses suspicious workflow runs stopped every public-repository run Wiz checked, but it does not cover private repositories or GitHub Enterprise Server.

Each workflow sits on a new branch named ci-sync- followed by six random characters. Deleting a branch, or the run it started, does not undo the exposure. Every secret the repository could read should be rotated, and the token that pushed the branch revoked.

Wiz has tracked the campaign since September 15 and calls it Gheist, after the user agent gheist that the attackers' tool sends with GitHub API requests.

Wiz has recovered more than 13,500 planted branches from more than 850 compromised accounts, from personal projects to the private repositories of enterprise organizations. Wiz's analysis does not say how many organizations had secrets exposed.

In private repositories and on GitHub Enterprise Server, GitHub audit logs show runs on the planted branches finishing and then being deleted by the gheist user agent. AWS CloudTrail logs show the organization's own workflows also running on those branches and assuming AWS roles, a sign that GitHub Actions ran there without approval.

In enterprise organizations, the tool cycled through tokens from several users and automation accounts within minutes and cloned private repositories before planting the workflow. Hours later, cloud credentials from the same organization were used to enumerate AWS Secrets Manager. Wiz's analysis does not say where those credentials came from or who used them.

As of October 24, the campaign was still running and changing. About two-thirds of the accounts involved were no longer available on GitHub. Wiz reported the activity to GitHub and says their disappearance likely reflects a response.

Anyone with write access to a GitHub repository can read every secret configured in it, according to GitHub's documentation. A stolen token with that access is enough.

For each repository a token can reach, the tool creates a ci-sync- branch and commits one file, .github/workflows/sync-check.yml, with the message ci: sync config. The commit is unsigned and includes the token owner's name; pushing it starts the workflow.

The workflow prints the job's environment and every secret the job can read, encoded in base32. GitHub masks secrets in logs, but its documentation says this is not guaranteed once a value has been encoded or otherwise changed. Wiz says the base32 text no longer matches the original secret, so it prints in full.

The workflow sets an empty permissions block. That limits the job's GITHUB_TOKEN, which the attackers do not need, and does not stop the job from reading secrets.

One version of the tool also runs a job for each deployment environment in the repository, so secrets limited to those environments print too. These are often production credentials, according to Wiz.

The tool then downloads the log through GitHub's API and deletes the run seconds later. Because the secrets leave through GitHub itself, there is no attacker server or outbound connection to block.

Since July 28, GitHub has held workflow runs it identifies as potentially malicious until a collaborator with write access approves them. GitHub says the hold "currently applies to public repositories on github.com only" and that GitHub Enterprise Server does not have it at this time.

Every public Gheist run Wiz checked, across all versions of the tool, was still waiting for approval, so its payload never ran.

The hold only catches runs that GitHub flags. A new variant of GhostAction, a separate campaign, ran in public repositories until GitHub began blocking it on October 9, according to research from security company GitGuardian. Wiz says Gheist is distinct from GhostAction, which uses different workflow files.

Around October 19, one version of the tool began pushing a second job meant for self-hosted runners, the machines organizations run themselves to process GitHub Actions jobs. It appears to target only repositories that have such a runner registered.

The job is written to search the runner machine for credentials, including 31 types of tokens: private keys, process environments, AWS instance role credentials, runner credential files, and the Kubernetes service account token. Wiz describes the job as buggy, and its analysis reports no successful run.

The sources Wiz could trace for the stolen tokens include infostealer logs and tokens exposed in earlier supply-chain attacks, such as the March compromise of the Trivy vulnerability scanner.

Other attackers also use the same accounts. On October 6, 391 accounts, many of them also used by Gheist, renamed about 1,461 repositories to appear to be cracked software and spread malware. The renaming wiped 610 of the planted branches.

Some victims also appear to be infected with PolinRider, malware that researchers have linked to North Korea. On October 19 and 20, three of them re-pushed their Gheist commits with a loader added to a vite.config.js file.

Megalodon, a campaign that pushed secret-stealing workflows into thousands of GitHub repositories in May, had also hit 57 of the accounts.

How to Check Your Repositories

Wiz recommends these checks:

• Look for branches named ci-sync- followed by six characters, where the only change is a new .github/workflows/sync-check.yml file with the commit message ci: sync config.
• In GitHub audit logs, look for workflow runs on ci-sync-* branches that were deleted within a minute of finishing, and for any activity from the user agent gheist.
• If your workflows sign in to a cloud provider with OIDC, check cloud audit logs for role assumptions or token exchanges whose subject includes a ci-sync- branch. This works even if you do not collect GitHub logs.
• On self-hosted runners, look for the files .gdmp_pat, .gdmp_patg and .gdmp_sweep, and the string gdmp-pivot in job logs.

OIDC lets workflows sign in with short-lived tokens instead of stored cloud keys. By default, a token's subject includes the branch name only when the job does not use a deployment environment, according to GitHub's OIDC documentation.

The published indicators are:

• User agent: gheist
• Branch: ^ci-sync-[0-9a-z]{6}$
• Commit message: ci: sync config, adding only .github/workflows/sync-check.yml
• String: toJSON(secrets) }}' | base32 -w 120
• String: ===== gdmp-pivot:
• File: .gdmp_pat
• File: .gdmp_patg
• File: .gdmp_sweep
• Git blob SHA (plain workflow): f3da2b8b357dcda02fd455d314be2a95007516a6
• Git blob SHA (timeout version): d09535857a741bbb976bdc084a9a021713133291
• Git blob SHA (separator version): 1dc5af9cce950aad1eb1546ecce8565b117540c4
• Git blob SHA (self-hosted job version): c665b778b2d822453293003e7ca0bbb2cb08e39d

Versions of the workflow that list a repository's deployment environments vary by repository, so they have no fixed hash.

What to Do If You Find a ci-sync Branch

Wiz advises these steps for an affected repository:

• Rotate every repository, organization, and environment secret the repository could use.
• Revoke the tokens that pushed the commits, and check their owners' devices for infostealers.
• If a ci-sync branch ran on a self-hosted runner, treat the machine and its cloud instance role as compromised.
• Do not approve held sync-check runs, and do not run code from ci-sync branches.

To make a stolen token less useful, Wiz also recommends these steps:

• Require reviewers on environments that hold production secrets.
• Limit OIDC trust policies to protected branches or environments.
• Use GitHub Apps or short-lived fine-grained tokens instead of personal access tokens.
• Run self-hosted runners as short-lived machines without Docker socket access or open access to cloud metadata.

A job cannot read an environment's secrets until a required reviewer approves it, according to GitHub's documentation.

from The Hacker News https://ift.tt/AI5aBm7
via IFTTT

Malicious File in Downloads Folder Tries to Trick AI Coding Agent Into Installing Malware

A malicious instruction file sitting in a developer's Downloads folder tried to make their AI coding agent install a known-malicious npm package, security firm Forever Security said in a report published last week.

The company caught the attempt on a real customer's machine and stopped the agent before any code ran. It could not determine how the file got into the folder.

The file was AGENTS.md, a plain-text instructions file that a coding agent, such as OpenAI's Codex, reads when it starts in a folder and follows as directions.

It was dressed up as ordinary engineering notes. One section told the agent to add a server to its own configuration and install a package called function-color from npm.

That package is part of a malware campaign that other researchers have documented separately: function-color pulls in a downloader called function-flag, which fetches and runs a Windows payload. Researchers at CloudSEK and Checkmarx, who analyzed the campaign, named it MALFEX.

Two things, each harmless on its own, make this work, Forever said. An agent is built to trust and obey the instructions file in the folder it opens. And a web page can save a file to the Downloads folder on its own, without a click or a permission prompt, choosing the name and contents. Put together, a web page can drop a file the agent will treat as orders into a folder the agent trusts.

Researchers did not establish that this is how the file was caught. To test whether the full path was possible, it built its own proof-of-concept page: visit it, and an AGENTS.md downloads silently into Downloads. Whether a real attacker used that route against the customer is not known.

The firm then reproduced the attack on two coding agents to show that it was not specific to a single product. Against Codex, it ran the real attacker file inside an isolated virtual machine. The file, framed as routine project setup, told Codex to register a server in ~/.codex/config.toml and run a command that installed the package.

Because that config file applies to every Codex session on the machine, the change would load the attacker's server in any folder afterward, not just Downloads. Codex ran the malware in more than 90% of attempts, Forever said.

Against Claude Code, the working attack looked different and succeeded less often. A planted CLAUDE.md, framed as internal gateway setup, tried to make Claude write an ANTHROPIC_BASE_URL into a project settings file, pointing its API traffic at a server Forever controlled. That one change leaks the session's login token, which is account takeover on its own, and lets the server reply as if it were the model and hand back commands the agent runs.

Claude needs a person to approve a write like that and often refuses one that looks wrong; the long engineering-doc framing got the write approved about half the time, researchers said.

There is nothing for OpenAI or Anthropic to patch, in Forever's view, because an agent following the instructions file in its folder is doing what it was built to do. The company compared it to a browser rendering a phishing page: the browser worked as designed, and the attack lies in the page. "There is nothing here for OpenAI or Anthropic to patch," Forever said.

What to do

Forever's advice is practical and needs no product:

• Do not start Codex, Claude Code, or any agent in ~/Downloads. It is the one folder the web can write to on its own.
• Look for instructions files you did not write. A stray AGENTS.md or CLAUDE.md, in Downloads or in a repository you just cloned, is the whole attack. Read it before you let an agent near it.
• Check the agent's own config. In ~/.codex/config.toml, watch for a server block or a changed base URL you did not add. In a project's .claude/settings.json, watch for an ANTHROPIC_BASE_URL or other API endpoint you did not set.
• Leave approval prompts and sandboxes on, and be wary of anything that tells the agent to switch them off.
• If you find a planted file, assume the login token leaked and rotate it. A stolen token is a live session, not just one caught request.

In its own telemetry, Forever said that about half of its customers run a coding agent in their Downloads folder, and roughly a quarter of agent sessions open a browser.

Those are the conditions the attack needs: an agent starts where the web can write, and, in many cases, an agent does the browsing itself, so no person is watching when a file arrives.

from The Hacker News https://ift.tt/qlTpa0v
via IFTTT

PHP2Shell Exploitation Hits Government Entity Amid Global Scanning and Signs of AI-Assisted Hacking

Threat actors have been observed using agentic artificial intelligence (AI) platforms for post-exploitation activity following the abuse of the PHP2Shell vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619.

"In one case, the attackers targeted a government entity in Europe and within two hours of the initial exploitation they had successfully accessed password hashes and multi-factor authentication secrets," Palo Alto Networks Unit 42 said.

"They also established an NT LAN Manager (NTLM)-relay tunnel into Active Directory and attempted Domain Admin privilege escalation."

The network security company said it also observed the unknown attacker enumerating the compromised endpoint, with commands and behavioral markers suggesting the work of an agentic attacker. These include commands to facilitate -

Reconnaissance of the authentication database with stolen credentials, targeting password hashes and two-factor authentication (2FA) secrets.

Active Directory (AD) reconnaissance via curl-based anonymous LDAP queries to the domain controller (DC) in an attempt to look for the administrator account.

Reconnaissance of the host to hunt for DNS/AD integration, internal hosts, privileged groups, and interactive users.

"Each command batch is wrapped in section-header delimiters, such as ==SHELLUSER== and ==PASSWD==," it added. "These delimiters produce machine-parseable output for an AI model to read."

Suspected N. Korea Campaign Targets PHP2Shell

The disclosure comes as CYFIRMA said it uncovered a suspected North Korea-linked campaign employing PHP2Shell to actively probe global PHP infrastructure from 21 compromised nodes.

"The scanning is deliberately low-volume and paced," Kumar Ritesh, CEO and founder of CYFIRMA, told The Hacker News. "Nodes are rotated and abandoned at the first sign of blocking or rate-limiting, so threshold-based alerting is unlikely to catch it."

The targets comprise a set of 216 unpatched or partially mitigated hosts located across the U.S., Japan, South Korea, Thailand, Indonesia, Australia, Taiwan, India, Singapore, the U.A.E., Saudi Arabia, and the E.U. The hosts span government, financial institutions, logistics, airports and aviation, manufacturing, and online transaction platforms.

"The campaign has moved from reconnaissance into active, low-and-slow scanning of a filtered target set," CYFIRMA said. "Organizations in the prioritised sectors and geographies should assume they are in scope for deliberate targeting."

The activity, coordinated via a closed I2P channel, has been attributed with moderate confidence to a Korean-speaking operator assessed to be affiliated with the Lazarus Group ecosystem. According to CYFIRMA, the two handles (전창혁 2 aka Jeon Chang-hyuk 2) and (최아린 aka Choi A-rin) active in the I2P channel have previously been observed running covert operations for the threat actors.

"Korean-speaking operators have used [the channel] to share target lists, exploit-hosting infrastructure, and tasking and prioritisation consistent with DPRK objectives," Ritesh said. "The captured conversation uses vocabulary and spelling specific to North Korean (Munhwaŏ) rather than the South Korean standard."

Other primary indicators that link the campaign to the Lazarus cluster are below -

• Command-and-control (C2) infrastructure that Lazarus has previously used to exploit web assets.
• Lazarus Group's documented history of compromising PHP and WordPress servers for C2 and planting of PHP and ASP web shells, as observed in the SyncHole watering hole campaign.
• Prioritizing government agencies and banks, specifically online transaction platforms, which is in line with Lazarus Group's track record of breaching financial institutions for financial and cryptocurrency theft.

"Exploitation is the next step," CYFIRMA said. "The operators said they would shortlist the most promising targets the same day and then choose which public exploits to adapt."

Other Exploit Efforts and Mitigations

In an October 25, 2026, post shared on X, Defused Cyber said it's also seeing PHP2Shell probes targeting its Palo Alto Networks GlobalProtect honeypots. The activity originates from 204.76.203[.]7, a known mass-exploit IP address.

"The requests carry a PHP_SESSION_UPLOAD_PROGRESS marker ('p2s-rider') and a dummy file upload with no payload, which points to someone checking for the vulnerable upload-progress behavior and likely building a target list of Palo Alto devices," the threat intelligence company said.

Both CVE-2026-109618 and CVE-2026-109619 are critical vulnerabilities that can lead to remote code execution in default PHP configurations. The security flaws have witnessed widespread scanning efforts, with Cloudflare stating it detected millions of exploitation attempts after public disclosure.

"An attacker faces two main constraints: they must size a request to fail allocation at the right moment, and they must defeat ASLR to find valid memory addresses," Datadog said. "The exploit needs one field name small enough to fit inside the accepted request body but large enough that copying its key exceeds memory_limit."

"When PHP parses a form-field name, it makes several copies along the way. The attacker uses that extra memory to force an allocation failure while PHP copies the name into a hash table."

ReliaQuest, in an update published on October 22, 2026, said it reproduced CVE-2026-109618 in a controlled lab and observed a sequence of errors that could help defenders identify exploitation.

"This testing identified a specific sequence of artifacts across PHP error, Apache access, Apache error, and system logs that may help defenders detect exploitation," it said. "Defenders should focus on the sequence: a POST request returns a 500 error, PHP reports memory exhaustion and heap corruption, and the Apache worker handling the request crashes."

The PHP Foundation has since warned of a third remote code execution vulnerability (CVE-2026-115560), which can only "occur under an unusual combination of configuration and application code." The issue is expected to be addressed as part of the regular release cycle.

"An application must set session.serialize_handler to php_binary or php_serialize in its configuration and then switch it to php at runtime with ini_set() before calling session_start()," the Foundation said. "Session upload progress must also still be enabled. Applications that never change the serialize handler at runtime can keep the feature enabled."

Xint has released a scanner to check if a host is exposed to PHP2Shell, stating remote code execution is possible in any PHP script regardless of the application and in applications where decoding occurs, such as with session_start() and unserialize().

Bitsight's internet-wide scans show that there are nearly 37 million internet-facing systems running PHP or PHP-related software, with most of the exposures in the U.S., Germany, France, the Netherlands, and Japan.

"PHP runs a very large portion of the web, from content management systems and online shops to bespoke internal tools," Bitsight said. "A flaw in the runtime can't be repaired by changing application code, and a web application firewall or plugin update won’t remove it. Only updating PHP on the host itself closes the gap."

from The Hacker News https://ift.tt/0rbGfxA
via IFTTT

Confidence or Con? The Psychology of Tech’s Boldest Leaders

Brian and Brandon take a detour from the usual tech news to ask a question every enterprise buyer of AI should be asking: why do some of tech’s most celebrated leaders project absolute confidence in claims that later prove false? Starting from the new Elizabeth Holmes documentary, they debate whether that kind of conviction is innate or learned. Brian argues it develops in stages, as each funding round and glowing press profile ties a founder’s identity more tightly to a story they must defend at all costs. Brandon describes a “contrarian effect,” in which a venture model with low hit rates rewards bold founders and tells them they are special. He recommends The Halo Effect as an antidote to success stories that confuse correlation with causation. They also question the VC preference for founders with hardship backstories. The conversation closes on Brandon’s framework of operators, believers, and pragmatists, and why every organization needs pragmatists willing to question big promises before they become fiction.

SHOW: 1074

SHOW TRANSCRIPT: The Enterprise AI Show #1074 Transcript

SHOW VIDEO: https://youtu.be/DXmB8_YwNRQ

SHOW SPONSORS:

• Nord Security - NordLayer AI Scout 

SHOW LINKS

• The Enterprise AI Show

GUEST BIO

N/A this week

FEEDBACK?

• Email: show @ the enterprise ai show dot com
• Bluesky: @TheEntAIShow.bsky.social
• Twitter/X: @TheEntAIShow
• Instagram: @TheEntAIShow

from The Cloudcast (.NET) https://ift.tt/uQAE5C0
via IFTTT

OpenAI AI Agents Demonstrate VM Escapes and Secret Cross-Sandbox Communication

OpenAI has announced plans to conduct frontier model training with no live internet access, as it resumes reinforcement learning (RL) training and internal inference of its most advanced AI models.

"Based on the current state of alignment research, monitoring systems, and the security of internet infrastructure, we believe the responsible approach is to conduct frontier model training with no internet access," the artificial intelligence (AI) company said. "We've implemented this policy and will maintain it until advances in these safeguards justify broader internet access."

OpenAI said models' growing capabilities can have the side effect of them getting much better at devising ways around environmental restrictions to escape containment and perform unintended actions. This can involve the model exploiting a software flaw or misconfiguration to reach the live internet, or finding unauthorized ways to communicate with agents in other sandboxes.

Late last month, the Frontier Lab made the decision to pause training of its most powerful models after one of its agents during reinforcement learning (RL) training contacted an external chatbot by exploiting a misconfiguration in a DNS resolver to obtain limited internet access.

OpenAI said it also kicked off a "high-compute red-teaming campaign" to test the resilience of its research and evaluation environments in the face of increasingly powerful models, leading to the discovery of previously unknown software vulnerabilities, including a critical unauthenticated remote code execution in Google Brotli (CVE-2026-111497, CVSS score: 9.2), a widely used compression library.

Patches for the vulnerability, also called Node2Shell and HTTP2Shell, have since been released for libbrotli, Python, C++, Node.js, Bun, Envoy, and Istio.

The red-teaming agents OpenAI dispatched to test its security safeguards also uncovered virtual machine escapes, novel paths to access the internet through vulnerabilities in metrics, logging, and authentication management services, and hardware side-channels for communication between agents, bypassing isolation boundaries.

"In one test that assumed compromise of a host machine, an agent reused a firewall-approved connection to reach a blocked authentication endpoint in our metrics service and then made that endpoint fetch a model-provided URL," it said. "In other tests, agents exploited misconfigurations that allowed blocked requests to pass through DNS and firewall controls, as well as ways to make services we run fetch external URLs."

In another experiment, after prompting the AI agents in separate microVMs to exchange synthetic secrets without relying on network connections or shared writable files, OpenAI said the digital bots found a way to communicate using the processor's cache via a timing-based side-channel.

Particularly, one agent is said to have encoded information by evicting selected data from the cache. A second agent measured the time it took to reload that data, leveraging the difference between fast and slow cache reads to recover the message.

"Once the agents agreed on a protocol for encoding and decoding these signals, they could exchange the synthetic secrets without changing a shared file or opening a network connection," OpenAI said.

The AI giant said the discoveries prompted it to strengthen its own safety and monitoring mechanisms and deem them sufficient enough to restart frontier RL training and internal inference, while continuing to invest in several key areas -

• Improving virtual machine security
• Probing cloud infrastructure for weaknesses
• Scanning source code and cloud configurations
• Testing monitoring and stopping systems
• Red-teaming sandbox and isolation guarantees

"After strengthening our containment architecture, we resumed our frontier RL training and inference on October 1," OpenAI said. "We've reserved substantial compute for continuous red-teaming, and made high-compute red-teaming part of the safety cases we use to decide whether frontier training and evaluation can proceed securely."

Earlier this month, Anthropic said it was cutting off live internet access for all its internal evaluations until further notice after discovering new incidents in which its AI models exhibited misaligned behavior and targeted real websites.

The disclosure comes as concerns have been raised over the ability of AI agents to detect and exploit software flaws, even in the guardrails designed to restrict them.

In a report published this week, third-party AI ​safety evaluators METR ⁠and Redwood Research said they found several new vulnerabilities in OpenAI's internal misalignment monitoring system as it existed before July 21, 2026, and during the time frame when the company's agents broke into model-hosting platform Hugging Face.

"We found a way Codex agents could in principle bypass Codex sandboxing and Auto-Review, allowing them to take any action that the host user could take," researchers David Rein and Adam Kaufman said. "We also discovered an exploit agents could use that would prevent hundreds of recent actions (including the actions involved in the exploit itself) from being monitored."

OpenAI is believed to have addressed all of the vulnerabilities affecting its production safeguards stack, although the safety organizations said they had not verified the fixes.

Anthropic's Mythos 5 Pursues an Unsanctioned Supply Chain Attack

The developments also coincide with a report from the U.K. AI Security Institute (AISI), which has found Anthropic's Mythos 5 model to be consistently taking unsanctioned actions even when presented with evidence that doing so would be out-of-scope and cause real harm (e.g., submitting a malicious code change).

The evaluation also revealed that the Mythos 5's chain-of-thought (CoT) reasoning process failed to consider the impact of harmful actions, with the model often producing invalid justifications that implied the target was simulated when asked if the human maintainer was real, but never generating incorrect justifications implying that it was real.

"Most models tested take a range of unsanctioned actions during simulated cybersecurity evaluations, Mythos 5 most frequently," AISI said. "Taken together, these observations could indicate that models are engaging in 'motivated reasoning': producing inferences and reasoning biased towards conclusions that justify continuing a particular approach to task completion."

In the most severe case, the model has been found to attempt a supply chain attack by submitting malicious code and creating five sock-puppet accounts to vouch for the changes and pressure a software maintainer into accepting it.

Responding to the findings, Anthropic has attributed the alignment failures to recklessness, biased reasoning, and an urge to "continue on its current trajectory" to a degree that disregards potential harm. The OpenAI rival also noted that its newer models, including an internal research model, are less susceptible to this behavior.

"Nevertheless, this incident serves as further evidence that current AI models are capable of surprisingly misaligned behavior in evaluation settings," it said. "We've built new evaluations that we run on new production models automatically, and we are specifically studying biased reasoning to better understand where it comes from in our training and how it affects our models."

from The Hacker News https://ift.tt/jbFvAd6
via IFTTT

Google Says Gmail and Photos Data Shared With AI Search Could Be Used for Targeted Ads

Google has updated its privacy policy to spell out that using personalized artificial intelligence (AI) features in Search or Gemini could allow the company to serve targeted ads to users based on their activity on other connected Google services.

"You may choose to allow certain Google services, including services like Search or Gemini Apps, to access data from other Google services you use, such as Google Photos and Workspace apps like Gmail and Drive, in order to provide you with a more personalized experience, subject to the policies and settings of the accessing service," reads a policy update effective October 16, 2026.

"For example, Search may process some of the data that you allow Search to access to personalize content, including ads."

Google also notes in its revised policy that "We don't show you personalized ads based on your content from Drive, Gmail, or Google Photos, unless you choose to make data from these services available to other Google services that support personalized ads."

News of the policy update was first reported by Android Authority.

Personal Intelligence, unveiled by Google in Gemini in January 2026, allows users to connect other services like Gmail, Google Photos, and YouTube as a way to provide tailored answers in combination with their chat history preferences.

The feature is currently rolling out as a beta to eligible users over the age of 18 globally, except in the European Economic Area, Switzerland, the U.K., and Nigeria.

It's worth noting that the policy states it doesn't use content from Gmail, Drive, or Photos to personalize ads by default. However, that changes should users opt to share photos or emails with AI Mode and other Search tools via the Personal Intelligence feature.

In other words, if users interact with AI Mode or Gemini while Personal Intelligence is enabled, the data that informs those answers (i.e., content from Gmail or Photos) could be used as a signal to serve targeted ads. The privacy policy aims to make it clear that feeding personal data into its AI tools could contribute to ad personalization.

Users should be mindful of the privacy trade-off when connecting their apps to enable AI features. Those who prefer to opt out can do so by selecting the apps they want to disconnect from Personal Intelligence or disable Personalized Recommendations entirely via the Search Services Personalization settings ("www.google[.]com/search-personalization").

In January 2026, OpenAI began showing ads to logged-in adult U.S. users in both the free and ChatGPT Go tiers, while emphasizing that users' data and conversations are protected and never sold to advertisers. It has also said the ads do not influence responses from the chatbot, and that users are in control of the experience.

Earlier this week, the AI company said it's expanded advertising on ChatGPT to 26 more countries, ​bringing the total to 89. This includes 14 more ​Latin American countries and several markets across Europe, Africa, and Asia.

"We keep conversations private from advertisers and do not sell customer data," OpenAI stressed. "Ads in ChatGPT are clearly labeled and separate from ChatGPT's answers, and advertising does not influence the answers ChatGPT provides."

from The Hacker News https://ift.tt/4bag6Ge
via IFTTT

Researchers Push Over 2 Million Updates to Remotely Disable Popcorn Time Updater That Could Fuel a Botnet

Between November 2025 and March 2026, the Dutch security firm Eye Security pushed more than 2 million updates to computers it did not own to switch off a background updater that it said could have allowed an outsider to take over the machine.

The updater belongs to Time4Popcorn, an abandoned copy of Popcorn Time, a free app that streamed pirated films and TV over BitTorrent.

Popcorn Time was popular about a decade ago, and the original shut down in 2014, but several copies kept running under the same name. A separate, legal project that took the Popcorn Time name in early 2025 is unrelated to it.

Eye Security, which monitors client networks for threats, found the updater during a routine threat hunt: a program called Updater.exe on one client's laptop kept trying to reach a web address that was no longer registered.

The firm registered the address itself to see what would connect, and about 50 requests a second poured in. It later laid out the operation, which it named Operation IXIM, in a write-up and a talk at Hack.lu on October 22.

Over six months, those requests carried more than 3.8 million different hardware IDs. The IDs proved an unreliable way to count machines, because some Windows PCs shared one and some Macs changed theirs, so Eye revised its estimate to 2.5 to 3 million Windows computers and 250,000 to 350,000 Macs.

The updater ran in the background on Windows and Mac from the moment the computer started. It checked for new versions over an unencrypted connection and installed whatever it was sent, at the highest privilege level, called SYSTEM on Windows and root on Mac, without checking who sent it.

Because the web addresses it called had been abandoned, Eye said, anyone who registered the right one could have served their own program to every machine still calling it.

On a machine with that access, an attacker could install ransomware, steal saved passwords, or pull the computer into a botnet, Eye said. Mapping a sample of the connecting addresses, the firm said it saw home users around the world, as well as machines on government, military, and corporate networks, though it added that it is "hard to draw conclusions" from that.

Eye had disclosed the flaw, now tracked as CVE-2026-30612, in June. The U.S. Cybersecurity and Infrastructure Security Agency rates it 9.8 out of 10. It affects three versions of the Time4Popcorn software:

• Windows, up to and including 6.2.1.18
• Mac, up to and including 6.2.1.17
• Android, up to and including 3.5.0.173

Turning the Updater Against Itself

With no company left to fix the software and no patch coming, Eye decided to use the updater against itself. After taking legal advice, it served the machines an update that does one thing: it stops and disables the updater, deleting no files and collecting nothing.

Eye compared the step to Operation Ladybird in 2021, when Dutch police pushed an update to computers infected with the Emotet botnet to disable the malware on them.

The difference, Eye said, is that Emotet's victims never chose to be infected, while Popcorn Time's users installed the app themselves. Still, the firm said, "none of them chose to have a forgotten updater running in the background for years."

Soon after the updates began, someone uploaded Eye's update to VirusTotal, and antivirus engines started flagging it as malware, a fair description of a program that disables a Windows service. Because every product that blocked it left the vulnerable updater running, Eye reworked the update until only one scanner continued to flag it.

By December 2025, Eye had updated more than 1 million systems and cut the traffic to its web addresses by about 90 percent. By March 1, it was sending about 5,000 updates a day, a 98 percent reduction. Judging the remaining numbers too small to interest a botnet operator, Eye stopped, having sent more than 2 million update downloads in all.

In late March, Eye handed the 15 web addresses it controlled to the Shadowserver Foundation, a non-profit that takes abandoned and malicious domains out of circulation, so a trusted party would hold them rather than Eye.

Public registration records for one of them, popcorntimeupd[.]xyz, now point to Shadowserver's sinkhole servers, with a transfer dated March 20, 2026. Other addresses the updater calls were never Eye's to take and remain with outside owners, the firm said, so machines that reach those are still exposed.

Eye found no sign that anyone else was serving code through the addresses: the ones already registered by other people were parked or up for sale, not pushing updates to the machines calling them. The flaw is not listed in CISA's catalog of known exploited vulnerabilities as of October 23, 2026.

What Popcorn Time Users Should Do

Switching off the updater does not make the app safe. Eye said Popcorn Time runs on a 2014 browser engine with its security sandbox turned off, loads content over unencrypted connections, and pulls in code from other abandoned web addresses.

Eye registered those abandoned addresses too, which it said would have let it run its own code on every machine that opened the app. It did not, but it built a working proof of concept, so the risk is real. The update only changed the updater, so the rest of the app remains dangerous for anyone who keeps using Popcorn Time.

Eye's advice is to uninstall Popcorn Time. The updater can also be turned off by hand: on Windows with two commands that stop and disable its "Update service," and on a Mac with one that unloads the PT.updd helper. Removing the app is the safer step, because disabling the updater leaves the rest of it in place.

• Windows: sc.exe stop "Update service"
• Windows: sc.exe config "Update service" start= disabled
• Mac: launchctl unload -w /Library/LaunchDaemons/PT.updd.plist

On Android, the updater is built into the app and cannot be turned off on its own, and it installs only if the user taps to accept, so Eye did not send updates to Android devices. Removing the app is the only fix there.

To check a network, defenders can look for the two updater files, Updater.exe on Windows and PT.updd on Mac, and for traffic to the web addresses in Eye's write-up, which lists all 20 domains and the file hashes.

from The Hacker News https://ift.tt/18AGctH
via IFTTT

Brotli Decoder Flaw Behind Node.js RCE Also Affects Bun, Python and Other Widely Used Software

A memory-corruption flaw in Google's Brotli decoder sits in many programs that unpack Brotli-compressed data, among them Bun, the Python Brotli and brotlicffi packages, and Envoy proxies set up to decompress Brotli.

Tracked as CVE-2026-111497, the flaw allows crafted compressed data to overwrite past the end of a buffer and corrupt a program's memory, potentially causing a crash, a memory leak, or the execution of attacker-controlled code.

Imperva researchers have shown that code can run on one unpatched Node.js build. The same has not been demonstrated on the other software, and no real-world attacks have been reported.

The flaw was first disclosed on October 21, when Node.js and Google shipped fixes, and more have followed product by product since. Because the bug is in Google's decoder and each program ships its own copy of it, every one has to update that copy on its own.

Brotli is a compression format from Google, used across the web to shrink pages and other traffic. The bug is in the C code that unpacks a Brotli stream, so it travels into anything that reuses that code, from language runtimes to proxies to Python packages.

Which Software Is Affected

Product	Affected	Fixed in	Exposed when
Google Brotli (C library)	1.0.3 to 1.2.0	1.0.10, 1.1.1, 1.2.1	code decodes untrusted Brotli
Node.js	22.x, 24.x, 26.x before the fix; 20.x and older (end of life)	22.23.4, 24.22.1, 26.12.1	fetch() of a br response, or Express or body-parser br bodies
Bun	1.4.3 and earlier	1.4.4	fetch() of a br response, or node:zlib
Envoy	1.39.2, 1.38.5, 1.37.7, 1.36.11	1.40.0, 1.39.3, 1.38.6, 1.37.8, 1.36.12	only if the Brotli decompressor is configured
Istio	1.31.0 to 1.31.1, 1.30.0 to 1.30.5, 1.29.0 to 1.29.8	1.31.2, 1.30.6, 1.29.9	only if Brotli decompression is enabled
Python Brotli	1.2.0 and earlier	1.2.1	installed, and an HTTP client decodes br
Python brotlicffi	1.2.0.x and earlier	1.2.1.0	installed, and an HTTP client decodes br
cdxgen	standalone binaries and images, 13.4.0 and 12.8.8 and earlier	13.5.0, 12.8.9	standalone binary or image scanning untrusted input

A program is exposed only if it decodes Brotli data that someone else controls. For Node.js and Bun, that happens when the built-in fetch() reads a response sent with Content-Encoding: br, or when request-body code such as Express 5 and body-parser 2 unpacks a Brotli upload. A plain Node.js HTTP server does not decode request bodies on its own.

Envoy and Istio are affected only when Brotli decompression is enabled, for example, through an Envoy filter. Where it is off, the flaw cannot be reached.

In Python, the risk comes from the Brotli or brotlicffi package being installed at all. Once either is present, HTTP clients such as requests, urllib3, httpx, and aiohttp decode Brotli responses on their own, so an application can be exposed without ever importing Brotli in its own code.

A web application firewall helps only so far. Vercel, which added firewall rules on the day of disclosure, said those rules do not cover "responses your functions fetch from other servers." For that path, only updating the runtime or library closes the hole.

How far the flaw can be pushed depends on the software. Imperva's Red Team, which calls its work Node2Shell, ran attacker-supplied code on an unmodified Node.js 24.22.0 build for Linux on ARM64, delivering it both as a fetched response and as an Express request body. The exploit took several tries, has not been released, and was not tested on other builds.

OpenAI, whose Codex Security team reported the flaw, describes it as enabling unauthenticated remote code execution in Brotli and lists Node.js, Bun, and Envoy as affected software. In its account, the flaw works both ways:

an unpatched server that accepts compressed input could be taken over by a malicious client, and an unpatched client that accepts compressed input (such as "curl --compressed") could be taken over by a malicious server.

No in-the-wild exploitation has been reported. CISA's October 23 assessment recorded exploitation as "none" and automation as "no," and Red Hat said there is no reliable public proof-of-concept for running code.

Severity ratings differ by who is scoring. Google, which assigned the CVE, rates it 9.2, or critical, on the CVSS 4.0 scale. Node.js calls it high, and Red Hat rates it 8.1, or important.

The fix has an unusual history. The change that closes the flaw was added to Brotli's source code on February 27, but no new Brotli release carried it until October 21. OpenAI said the root cause "was actually fixed in the Brotli source code in February, but it wasn't known at the time that it gave rise to a security vulnerability and there was no more recent release of Brotli."

Node.js credits Khai Tran and Sylvie Mayer of OpenAI's Codex Security for reporting the flaw, and maintainers Matteo Collina and Antoine du Hamel for the fix.

What to Do Now

Update to a fixed version from the table above, then restart the service and rebuild any container image, because a running process keeps the old decoder until it restarts.

Where you cannot update yet, stop decoding untrusted Brotli. OpenAI's disclosure page and the security firm Aikido both recommend:

• Reject incoming requests with Content-Encoding: br before any proxy or parser decodes the body.
• Turn off automatic Brotli decoding in HTTP clients, and reject Brotli responses before they are decoded.
• In Python, uninstall the Brotli and brotlicffi packages so clients fall back to gzip and deflate.

Dropping br from the Accept-Encoding header does not help on its own, because a server can send Brotli whatever the client asks for. For Node.js, no workaround has been published, so updating the runtime is the only fix.

System packages are being fixed at different times. Debian fixed its brotli package for Debian 13 (trixie) on October 23 in version 1.1.0-2+deb13u1. Amazon Linux 2023 still listed its brotli and Node.js 24 packages as pending a fix as of October 22.

Dependency scanners may not flag the Python packages yet. The CVE record names Google's Brotli repository, not the PyPI packages, and GitHub's advisory still lists no affected package, which is what Dependabot reads. Advisory entries for the two Python packages, PYSEC-2026-4322 and PYSEC-2026-4323, were added on October 23, so check the installed versions manually as well.

from The Hacker News https://ift.tt/sMh6Kvq
via IFTTT