Aoki, also known as Aokigahara, is a data-stealing malware that has added credentials for AI tools to its growing list of targets. Recent versions seek local files and session data linked to ChatGPT, Claude, OpenAI Codex, Cursor, Codeium and Gemini.

The change raises the risk for developers who use AI assistants alongside source-code repositories, cloud accounts and other work systems.

Unlike a flaw in an AI service, Aoki’s activity focuses on data stored on an infected computer. A stolen key or token may let an intruder use an account as its owner, run up paid usage or reach services connected to that account.

Earlier Aoki samples did not search for AI-related files, suggesting this is a newer addition to the malware’s collection rules. Researchers from Symantec’s Threat Hunter team identified the expanded targeting.

Symantec’s Threat Hunter team analysis found that newer Aoki versions search for files linked to Claude, ChatGPT and Codex, as well as tokens used by services such as GitHub Copilot, Cursor, Google Gemini, JetBrains AI Assistant and Kiro.

The Symantec Aoki threat report also describes the malware’s wider reach across browsers, wallets and messaging apps. The files named in the report include .claude.json, Claude desktop cookies, ChatGPT cookies, and Codex config.toml and .env files. These can contain login sessions, settings or secrets used by local tools.

Aoki also targets Cursor’s local state database, which may hold chat context and code snippets. Symantec says the main focus is credentials and session data, rather than source code itself.

New Aoki Malware Targets ChatGPT, Claude, Codex and Gemini

Aoki does not stop at AI tools. It can collect browser cookies, saved passwords, autofill details, credit-card data and Google tokens from a broad range of browsers.

Its other targets include cryptocurrency wallet files and extensions, password managers, VPN and file-transfer applications, gaming services, and Telegram and Discord data. It also records which security products are installed on the computer.

That broad collection can turn one infected device into a source of access to several accounts. For developers, a stolen token may expose more than an AI subscription: connected repositories, cloud services and continuous integration and delivery pipelines could also be at risk.

The growing focus on locally stored agent data has been seen in other reporting on AI coding agent data theft, though that coverage describes other malware families, not Aoki.

Aoki sends collected information to a command-and-control server using a /gate endpoint. Symantec says newer samples used several domains, while older samples used an IP address and port 8080 over unencrypted HTTP.

The report does not name a threat group behind Aoki, and it does not link the malware to a known family. Its name comes from “Aokigahara,” a string used during the malware’s decryption process.

The theft of AI credentials can also lead to direct costs. An intruder may use a victim’s account quota or resell access; abusing paid AI services in this way is often called LLMjacking. A separate report on stolen AWS keys used for LLMjacking shows how compromised cloud credentials can be used to run paid AI models at the account owner’s expense. Aoki’s reported focus, however, is stealing data from infected devices.

This pattern is not limited to Aoki. Cyber Security News has reported on a fake Gemini npm package that targeted credentials and local data from several AI development tools.

The incidents underline why developers should treat AI configuration files and local session data as sensitive, much like cloud keys and source-control credentials.

What defenders should check

Organizations should look for the indicators below in endpoint and network records. A match is a reason to investigate, not proof on its own that a device is infected.

If a system is suspected of compromise, teams should use a clean device to revoke active AI sessions, rotate exposed API keys and related credentials, and review account activity.

They should also check connected repositories and cloud services for unexpected use. These steps matter because multi-factor authentication may not stop an attacker from reusing a token already stolen from a device.

Developers should avoid saving long-lived secrets in files that are accessible to local applications, limit tokens to the permissions and time needed, and remove or replace exposed keys.

Security teams can monitor for unexpected access to AI tool folders and unusual outbound connections, then compare findings with the indicators below. Symantec identifies the family as Infostealer.Aoki.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post New Aoki Malware Targets ChatGPT, Claude, Codex and Gemini to Steal Credentials appeared first on Cyber Security News.

A critical vulnerability in Ghostscript could allow attackers to use specially made PDF files to run code on vulnerable servers.

The flaw, tracked as CVE-2026-39919, affects Ghostscript versions before 10.08.0 and has a CVSS severity score of 9.8 out of 10. Ghostscript is widely used to render PDFs, create document thumbnails, and convert PostScript files into images.

The issue is especially important for websites and services that accept uploaded PDFs. WordPress sites, document portals, print services, email gateways, invoice platforms, and file-conversion APIs may all call Ghostscript behind the scenes when they process user-supplied files.

A malicious PDF can therefore reach the vulnerable component even when the main application has no direct Ghostscript code.

Researchers from Wordfence identified the vulnerability during a WordPress 7.1 security assessment using its Argus testing system.

This is not a malware campaign, and researchers have not reported active exploitation in the wild. Instead, the finding shows how a crafted PDF can trigger memory corruption and, in certain server builds, lead to unauthenticated remote code execution.

Wordfence reported the flaw to Artifex on August 23, and the vendor confirmed it the following day before releasing the fix on September 8.

Critical Ghostscript Flaw

CVE-2026-39919 is a heap-based buffer overflow in Ghostscript’s JPEG 2000 image decoding path. The issue occurs when Ghostscript processes a PDF containing a JPEG 2000 image with unusual component resolution settings and sub-byte sample values.

In simple terms, the program reserves too little memory for image data and then writes more data than the allocated buffer can hold.

That extra data can overwrite nearby memory used by Ghostscript. In a controlled WordPress test environment, Wordfence researchers showed that this memory corruption could be developed into remote code execution.

The code would run with the permissions assigned to the account that processes the PDF, such as a web server or PHP-FPM user, rather than automatically gaining root access.

The public NVD vulnerability record lists the issue as a heap-based buffer overflow and notes that crafted JPEG 2000 content inside a PDF can corrupt memory.

The risk starts when an application accepts a PDF and attempts to create a preview or thumbnail. On many WordPress setups, the chain is WordPress, Imagick, ImageMagick, and then Ghostscript. The site may appear to be processing a normal document upload, but Ghostscript is the lower-level tool that reads the file.

This is why the issue differs from the earlier WordPress Imagick code-execution flaw, where WordPress upload validation could be bypassed with content disguised as an image. In this case, the memory bug itself sits inside Ghostscript.

Affected Versions and Real-World Risk

The vulnerable code was introduced in Ghostscript 9.21 and affects upstream versions through 10.07.1. Artifex fixed the issue in Ghostscript 10.08.0, and its official Ghostscript CVE page confirms that CVE-2026-39919 was addressed in that release.

However, Linux vendors may backport the fix to an older-looking package version, meaning gs --version alone may not prove whether a server is safe.

Wordfence tested ten package environments, including Debian, Ubuntu, Fedora, AlmaLinux, Alpine Linux, and an official WordPress Docker image. The researchers found vulnerable builds across those environments during their September 15 tests.

Their proof-of-concept files did not work unchanged across all systems, which means there is no evidence of a single universal PDF that compromises every server. Still, a build-specific exploit continued to work on systems sharing the same Ghostscript executable.

That result matters for hosting providers and companies that deploy many servers from one container image. A threat actor may not need a PDF that works everywhere if several targets use the same vulnerable build.

The concern is similar to the recent malicious HEIC image research, which showed how native media-processing libraries can expose WordPress servers when uploaded files reach vulnerable decoders.

Organizations should install the fixed Ghostscript package provided by their operating system vendor or hosting provider. Teams using containers should rebuild images from an updated base image and redeploy them, rather than simply restarting an existing container.

Managed WordPress customers should ask their hosting provider whether its Ghostscript package includes the CVE-2026-39919 fix and whether uploaded PDFs are converted into previews.

Where updates cannot be installed immediately, administrators should stop untrusted users from uploading PDFs or disable PDF processing through ImageMagick policy settings.

Rate limits and upload limits can reduce repeated processing attempts, but they do not remove the underlying flaw. Ghostscript’s -dSAFER mode should also not be treated as a fix because Wordfence reached the vulnerable path while that sandbox setting was enabled.

The incident also adds to growing evidence that document and image conversion services need close review. A Discourse image pipeline chain recently showed how Ghostscript and ImageMagick can become part of a wider file-processing risk path.

While Claude-assisted decoder exploit research demonstrated how flaws in media libraries can be adapted for real service environments.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Critical Ghostscript Flaw Lets Attackers Use Malicious PDFs to Execute Code appeared first on Cyber Security News.

Hackers are turning trusted software updates into a route for stealing developer and cloud credentials. Recent supply chain incidents show how a single altered package, build action, or publishing token can place malware inside routine development workflows.

The risk is not limited to one product or programming community. After obtaining a maintainer token or access to an automated release pipeline, attackers can deliver code through an update that users and security tools may already trust.

ReversingLabs said in a report shared with Cyber Security News (CSN) that S1ngularity, Shai-Hulud, and TeamPCP show how quickly a compromise can spread from one supplier to many downstream organizations.

The report describes a chain of stolen credentials, poisoned releases, and repeat attacks across open source ecosystems.

The consequences reach beyond a developer laptop. Stolen GitHub, npm, cloud, and SSH credentials can expose source code, cloud resources, deployment systems, and other packages. In several cases, malware used credentials taken from one victim to publish the next poisoned update.

Hackers Poison Trusted Software Updates

The S1ngularity incident illustrates why trusted software distribution is a valuable target. Attackers compromised Nx packages after using a crafted pull request to obtain a token, replace a CI script, and trigger a publishing workflow.

The infected packages then ran post-install hooks on developer machines, a pattern detailed in CSN’s coverage of Nx package credential theft during the 2025 campaign.

Those hooks searched for valuable data, including tokens, credentials, and SSH keys. They also used GitHub credentials found on the host to create public repositories, giving the attackers a direct route to retrieve stolen material.

The campaign was unusual because its malicious code also prompted local AI tools to search the file system for likely credential locations.

The report, published September 30, 2026, places the Nx compromise on August 26, 2025. It treats the original campaigns separately from TeamPCP, whose involvement in earlier incidents remains unproven.

The report says the prompts sought leads to GitHub and npm tokens, cloud credentials, and SSH keys. This makes the attack more than a conventional password stealer: it attempted to turn a developer’s own assistant into a local discovery tool.

Readers can see the broader impact in AI tool credential targeting, including the data the malware sought from affected systems.

S1ngularity also showed why long-lived publishing tokens are risky. The stolen npm token enabled infected packages to be released, while compromised updates gained the benefit of an established package’s reputation.

Nx later adopted a trusted-publisher approach using short-lived, per-run credentials, reducing the value of a token stolen from a repository.

Credential Worms

Shai-Hulud expanded this model by making it self-propagating. The worm searched compromised systems for npm publishing credentials, used them to identify packages a victim could publish, and inserted malicious code into further releases.

That let it spread without a separate software flaw at each target, as explained in the Shai-Hulud worm attack investigation. Later activity attributed to or associated with TeamPCP showed how attackers can reuse an earlier breach.

In the Trivy incident, a privileged token was extracted in February 2026, but incomplete credential rotation left a path for attackers to publish a malicious update on March 19 through an automated system.

The attackers altered version tags used by CI/CD workflows, a technique covered in CSN’s report on Trivy tag poisoning attack. The credential-stealing payload targeted running workflows, where secrets can be especially valuable.

After the Trivy compromise, the group used harvested npm tokens to distribute CanisterWorm, which compromised more than 60 npm packages. Checkmarx, LiteLLM, and Telnyx were also affected, showing how stolen access can support successive intrusions.

Organizations should treat a poisoned update as a potential full credential compromise. They should replace long-lived publishing secrets with short-lived credentials, tightly limit token permissions, pin CI/CD dependencies to reviewed commits, and monitor publishing and repository activity for unexpected changes.

Teams that may have run an affected release should rotate exposed tokens promptly and check for unauthorized repositories, workflows, and package publications.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC

The post Hackers Poison Trusted Software Updates to Steal Developer and Cloud Credentials appeared first on Cyber Security News.

A flaw in a custom session-cookie system allowed an unauthenticated attacker to pose as employees and administrators in a yard management platform.

The issue did not break Microsoft Entra ID itself. Instead, it let a weak application-side session layer accept a forged identity after the normal sign-in controls had been bypassed.

The affected platform used Entra ID single sign-on and multi-factor authentication, but also relied on a signed cookie to maintain application sessions.

That design created the same risk seen in cookie-based account takeover attacks, where control of a trusted session can matter more than a password.

Resecurity said in a report shared with Cyber Security News (CSN) that its authorized assessment uncovered the weakness while reviewing a supply-chain yard management system.

The researchers said no production systems were tested, test records were restored, and the identities referenced in the proof of concept were anonymized.

Researchers successfully impersonated 95 employee accounts from 241 tested user IDs, including accounts with elevated rights. A forged administrator session was able to perform a state-changing API request, meaning the flaw could expose operational data and let an intruder act under a legitimate employee’s identity.

Session Cookie Vulnerability

The bypass came from two linked design errors. The application signed a cookie with a hard-coded secret that matched the cookie name, while the signed value was a user’s publicly exposed database identifier. Neither value should have been sufficient to establish an authenticated session.

A signed cookie normally detects changes by applying a server-held cryptographic secret to a random session reference. Here, the target CUID could be obtained from API responses, including the authenticated-user endpoint and directory responses.

With a predictable secret, an attacker could make a cookie the server treated as belonging to another user. That distinction matters because the resulting request never needed the victim’s password, a fresh MFA approval, or an Entra ID access token.

It was a failure in the application’s trust model, not evidence that Entra ID cryptography was compromised. Recent reporting on Entra refresh token theft similarly shows why identity defenses must protect the artifacts issued after sign-in.

The platform’s broader controls appeared sound during testing: it used RS256-signed access tokens, schema validation and parameterized database access.

However, the separate session cookie became an alternate route into the application. The researchers also found an unauthenticated Swagger interface that exposed the full 251-route API surface, giving the assessment added visibility.

Containing the Session-Layer Risk

The priority is to rotate the compromised session-signing secret and invalidate existing sessions. This cuts off cookies produced with that key.

Teams should then review authentication and application logs for unusual session creation, account changes, administrative actions, or activity that does not match the expected user or device.

Developers should replace identity-bearing, client-controlled session values with randomly generated session identifiers stored and verified on the server.

Separate, high-entropy secrets should be held securely for development, staging, and production, never reused across environments. A secure cookie flag alone cannot protect a session design that trusts a predictable value.

Organizations should also assess every custom layer added around a cloud identity provider. Strong upstream single sign-on and MFA cannot compensate when an application accepts a separate credential as decisive proof of identity.

Defenders can apply lessons from the Cookie-Bite session hijacking technique, including monitoring suspicious sign-ins, restricting unapproved browser extensions, enforcing compliant-device access, and applying token protections.

If stateless tokens remain necessary, Resecurity recommends strong cryptographic keys, expiration limits and replay protections. Teams should ensure session revocation covers every host that accepts the cookie.

The same forged cookie in this case worked on both the API and administrative application hosts. Reports on Microsoft 365 session theft have likewise stressed that password resets alone may not terminate authenticated sessions.

The case is a reminder that MFA verifies a login event, while session management decides what happens afterward. A random server-side session reference, rotated secrets, and meaningful monitoring reduce the chance that an attacker can turn an exposed identifier into account impersonation.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC

The post Session Cookie Vulnerability Lets Attackers Bypass Entra ID MFA and Impersonate Users appeared first on Cyber Security News.

A specially crafted image file was enough to turn a normal upload feature into a potential path to server takeover. Researchers have shown that a flaw in widely used image-decoding software can corrupt memory and, in certain cases, allow attackers to run code remotely on affected systems.

The issue, named HEIF Heist, affects applications that accept and process HEIF, HEIC, or AVIF images. Instead of relying on a conventional malware download, an attacker can hide the trigger inside an image submitted through an upload feature, placing web services, developer platforms, and enterprise tools at risk.

CyberScoop noted that Hacktron researchers used AI-assisted research to uncover and test the weakness. Their work raises concern because image files often pass through trusted conversion tools, while the libraries behind them may process hostile content before normal application defenses can stop it.

CyberScoop said in a report shared with Cyber Security News (CSN) that no active malware campaign was identified in the disclosure, and the researchers conducted controlled proof-of-concept testing.

Still, the potential impact was broad, including exposure of in-memory information, user files, access tokens, account sessions, and production systems where an unpatched decoder processes attacker-supplied images. This makes ordinary media-handling infrastructure a potential gateway into far more valuable systems.

Claude Opus 5 Helps Researchers Weaponize HEIF Image Flaw

The core weakness sits in the way libheif and libde265 parse certain image data. Hacktron found that malformed HEIC images could reach the underlying decoder through an application upload pipeline, triggering a heap-buffer overflow that provided the building blocks for reading or changing memory.

The researchers said AI systems assisted their investigation, with Claude Opus 5 helping turn the flaw into a working remote-code-execution path.

In testing described by Cyber Security News’ earlier coverage, the target forum processed HEIC files through ImageMagick after its usual image-validation component did not support that format.

Crafting a reliable exploit still required target fingerprinting and payloads tailored to the installed version. Some attempts needed thousands of uploads, but AI-assisted work reduced the reported time from an initial probe to RCE to roughly one to three days.

One proof of concept involved a Discourse-based community forum, where the researchers chained flaws to compromise employee accounts and use associated credentials to open a pull request in an internal code repository.

The team said the initial flaw was found on July 25, patched within days, and led to a $6,500 bug bounty. The finding also echoes recent Next.js image risks, where a vulnerable AVIF-processing path could expose servers to RCE.

In both cases, the danger comes from treating an image upload as harmless while an underlying component performs complex parsing on the server.

Patch Decoders and Isolate Uploads

Organizations should identify every service that accepts HEIF, HEIC, or AVIF uploads, including support forums, content platforms, APIs, and internal developer tools.

They should then confirm that deployed libheif and libde265 packages include the latest upstream security fixes, not merely the version supplied by an older base image.

Updating only the front-end application is not enough when the vulnerable code lives inside a container, operating-system package, or conversion dependency.

Teams should review software inventories and rebuild images where necessary, a lesson also seen in WordPress image processing flaw, where careful inspection of real file content was central to the fix.

Where image conversion is essential, operators should disable unused decoders and run conversion in short-lived, isolated environments with minimal permissions.

Limiting access to credentials, source repositories, and sensitive environment variables can reduce the blast radius if a parser is compromised.

Finally, upload services should enforce file-type checks, size limits, logging, and monitoring for repeated failed processing attempts.

The broader pattern matches Rails file-processing exposure: an upload endpoint can become a route to secrets or code execution when server-side media handling is not treated as a high-risk boundary.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC

The post Claude Opus 5 Helps Researchers Weaponize HEIF Image Flaw Into Remote Code Execution appeared first on Cyber Security News.

Confidential cloud systems are designed to keep a customer’s data hidden even from the server operator. DDRop shows that this promise can fail when an attacker can tamper with the DDR5 memory path.

The new technique is a physical hardware attack, not malware, but it can undermine workloads protected by Intel TDX and AMD SEV-SNP.

Earlier work had already raised questions about trust boundaries in confidential virtual machines. In earlier TDX isolation findings, researchers showed that a hostile virtual-machine manager could observe activity patterns inside a protected trust domain.

DDRop moves the concern below software, targeting memory commands travelling between a processor and server memory.

Researchers behind the published GitHub research materials said in a report shared with Cyber Security News (CSN) that DDRop uses a custom DDR5 registered DIMM interposer to interfere with memory writes at normal operating speeds.

The project includes hardware designs, controller firmware, host tools, and proof-of-concept attack code for the affected platforms. The attack requires privileged control of the target host and brief physical access to install the device.

That makes it less likely to affect ordinary endpoint users, but it creates a serious risk model for cloud infrastructure, colocation facilities, and other environments where attackers may access servers during maintenance or supply-chain handling.

New DDRop Attack Breaks Intel TDX

The researchers built the interposer for $159 in parts, excluding development time and assembly costs. It sits between the CPU and a DDR5 RDIMM, then manipulates command signals instead of reading ordinary application data.

The design can trigger parity failures, causing the memory module to reject selected write commands while the system is not properly alerted.

When a write is silently discarded, a protected virtual machine can later read older data that should have been replaced. This is the core DDRop primitive.

The researchers found that Intel TDX, Intel Scalable SGX, and AMD SEV-SNP can be affected because scalable memory-encryption designs do not fully verify whether encrypted memory contains the freshest version of each cache line.

That distinction matters. Encryption can keep a memory value unreadable to an attacker, yet it does not necessarily prove the value is current.

Similar lower-level risks were highlighted in recent DRAM scrambling analysis, where researchers examined how changes beneath the operating system can bypass controls that assume memory addresses remain stable.

TDX and SEV-SNP Security Impact

DDRop becomes more damaging when it is combined with trusted memory-management interfaces exposed to a malicious host. The researchers showed that an attacker could interfere with page relocation and force a destination page to retain stale contents.

In testing, this enabled deterministic copying of plaintext between pages belonging to the same confidential virtual machine. On Intel TDX, the team also demonstrated injection of malicious Secure Extended Page Table entries.

This can give an attacker control over protected address translations, opening a route to victim ciphertext access, replay attacks, and corruption of sensitive control structures.

The researchers further showed attacks that could place a trust domain into debug mode or forge an expected attestation measurement. The most durable fix requires hardware designs that provide both cryptographic integrity and freshness checks, the researchers said.

Until then, organizations should limit physical access to servers, monitor firmware and memory configuration changes, use attestation carefully, and disable memory-management features that are not required.

Broader AI data center hardening practices, including firmware baselines and hardware inventory controls, can also help reduce exposure to physical platform attacks.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.

The post New DDRop Attack Breaks Intel TDX and AMD SEV-SNP With $159 DDR5 Device appeared first on Cyber Security News.