The malware is sold through a malware-as-a-service model. Its operators advertise a tool designed to evade Windows Defender and other antivirus products. However, these claims are not proof that every version can bypass security protections.

Researchers at Group-IB analyzed KGB RAT and found several dangerous capabilities, including credential theft, remote desktop access, keylogging, and ransomware-related features.

KGB RAT Malware and Its Evasion Techniques

According to Group-IB’s research, KGB RAT has been promoted on underground forums as a commercial malware tool. The sellers offer a payload builder that can generate files in formats such as EXE, BAT, HTA, and REG.

Researchers found that analyzed samples were based on an obfuscated version of NjRAT, an existing remote access trojan.

Once executed, the malware can attempt to establish persistence and collect information about the infected computer. Group-IB observed several techniques, including:

• File disguise: The malware copied itself into a temporary folder and relaunched under the name svchost.exe, resembling a legitimate Windows process.
• Scheduled task creation: It created a task named ChromeUpdate to help it run again when the user signs in.
• System changes: It modified Windows settings related to hidden files and security warnings.
• Security checks: It collected information about running processes, installed security products, and the operating system.

These activities can help the malware remain active and gather information about the environment.

How KGB RAT Steals Data and Controls Computers

KGB RAT combines several capabilities that can put personal and business information at risk.

Group-IB’s analysis identified features designed to:

• Steal credentials: Access Windows Credential Manager files containing saved sign-in information.
• Record activity: Capture keystrokes, screenshots, and clipboard contents.
• Control devices remotely: Use remote desktop functionality, including a hidden VNC feature.
• Monitor cryptocurrency transactions: A Crypto Clipper component in an analyzed sample could potentially replace copied cryptocurrency addresses.
• Communicate with attackers: Send infection notifications through Telegram and contact command-and-control (C2) servers for instructions.

The researchers also observed the sample checking for virtual machines and analysis tools. Such checks may help malware operators identify environments used for security research.

The seller advertises a crypter intended to hide the malware from antivirus detection. However, Group-IB reported that its analysis platform detected samples through their behavior, demonstrating why obfuscation alone does not guarantee evasion.

How to Protect Windows Systems

Organizations should focus on preventing unauthorized execution and detecting suspicious activity.

Recommended measures include:

• Keep Windows and endpoint protection software updated.
• Block unapproved applications and suspicious executable files.
• Monitor unusual scheduled tasks, especially those created by programs running from temporary folders.
• Investigate unexpected registry changes and suspicious outbound connections.
• Watch for unusual credential access, keylogging behavior, and remote desktop activity.
• If infection is suspected, isolate the affected device, investigate the incident, and reset exposed credentials from a clean system.

KGB RAT highlights the risks posed by commercially distributed malware. Even when attackers rely on existing malware code, a combination of credential theft, persistence, and remote control can create serious security consequences.

For defenders, the priority is not simply identifying a suspicious file. It is detecting the behavior that reveals an attack and responding before sensitive information is compromised.

IoCs

The post KGB RAT Bypasses Windows Security to Hijack PCs appeared first on First Hackers News.

According to researcher Sunil Tripathy, the attack involves hidden instructions placed in a public repository. When ChatGPT reviews the repository, the instructions may influence the AI agent to perform actions in another private repository connected to the user’s account.

The researcher assigned the finding a CVSS 4.0 score of 9.3. This is the researcher’s assessment, not a confirmed vendor rating. His testing reportedly used accounts he controlled and a dummy secret.

How the Attack Could Work

The reported attack uses a technique called indirect prompt injection, in which an AI system encounters malicious instructions inside content it is asked to process.

The researcher describes a scenario involving two GitHub accounts: one controlled by an attacker and another belonging to the user who connected GitHub to ChatGPT.

The attack reportedly follows these steps:

• The attacker adds hidden instructions to a public repository.
• The victim asks ChatGPT to review that repository.
• The AI agent follows the malicious instructions and attempts to modify another private repository.
• A GitHub Actions workflow is added and runs automatically.
• The workflow allegedly sends a dummy secret to an external server.

The researcher also reports private repository discovery and unauthorized file changes. These findings have not been independently verified.

What Makes This Report Important?

The reported behavior raises concerns about how AI assistants handle untrusted repository content and permissions granted to connected services.

However, the exact integration involved remains important. OpenAI’s GitHub connection documentation describes the standard ChatGPT GitHub app as read-only, while Codex supports code editing and pushing. This difference means the affected product, permissions, and execution path need clarification.

The researcher says he reported related behavior on September 4, demonstrated the test scenario on September 28, and received an out-of-scope closure on October 14. He also claims the behavior remained reproducible on October 15. These statements do not establish that OpenAI has confirmed the issue or that a security patch is available.

Recommended Security Measures

Organizations using AI tools with GitHub should take steps to limit potential exposure:

• Restrict repository access: Give connected applications access only to repositories they need.
• Review workflow changes: Investigate unexpected GitHub Actions files, commits, and repository modifications.
• Protect sensitive credentials: Avoid exposing secrets to untrusted workflows and rotate credentials if exposure is suspected.
• Review application permissions: Regularly audit connected GitHub apps and remove unnecessary access.

The key lesson is that AI assistants must treat repository content as untrusted input. Limiting permissions and reviewing automated actions can help reduce the impact of malicious instructions.

As AI-powered development tools become more integrated into software workflows, access control and careful handling of untrusted content remain essential parts of software supply chain security.

The post ChatGPT GitHub Integration Flaw: Risks to Private Code appeared first on First Hackers News.

Tracked as CVE-2026-105445, the vulnerability involved personal access tokens that were transferred to another account during organization conversions. Docker fixed the issue on September 30, 2026, and reported no evidence of exploitation.

The flaw created a potential software supply chain risk because developers and businesses could unknowingly rely on altered container images.

How the Docker Hub Flaw Worked

Docker Hub allows users to convert personal accounts into organizations while keeping their existing repository names. However, a problem with this process caused personal access tokens (PATs) to be transferred to the selected organization owner without changing the token secret or notifying the owner.

An attacker could create an account, generate a token, and convert the account into an organization while selecting a victim as its owner. The token could then authenticate as the victim, potentially allowing unauthorized access to repositories.

Depending on the token’s permissions, an attacker could:

• Upload or modify container images.
• Access images in personal repositories and connected organizations.
• Delete images within the token’s permitted scope.

The flaw did not allow full account takeover or access to the victim’s password, email settings, or two-factor authentication controls.

Docker’s Investigation and Fix

The vulnerability affected account conversions from August 26, 2024, until Docker deployed its fix on September 30, 2026.

Docker reviewed account conversions, token records, registry activity, and approximately 304,000 image pushes associated with transferred tokens. The company reported no evidence of malicious exploitation or suspicious image modifications linked to the flaw.

Docker subsequently notified affected users and organization owners. On October 8, it deactivated transferred tokens, except those owners requested to retain.

Recommended Security Measures

Organizations using Docker Hub should review their access tokens and container publishing processes.

• Review personal access tokens: Revoke unfamiliar or unnecessary tokens and check their permissions.
• Secure automation: Consider organization access tokens for organizational workflows.
• Verify container images: Review image provenance and scan images before deployment.
• Monitor repository activity: Investigate unexpected image pushes, modifications, or deletions.

Docker has also stated that it is improving the account conversion process with owner consent, notifications, and records of token ownership changes.

This incident highlights the importance of protecting credentials and verifying the integrity of software supply chains. Even when an account appears legitimate, weaknesses in identity and token management can create opportunities for unauthorized access.

The post Docker Hub Flaw Allows Impersonation, Image Tampering appeared first on First Hackers News.

The flaws, tracked as CVE-2026-108184 and CVE-2026-108185, have CVSS v3.1 scores of 7.4. Zoom Offensive Security reported both issues in security bulletins dated October 13, 2026.

The available advisories describe information disclosure risks but do not confirm the exact information that could be exposed or whether attackers have exploited the flaws.

Zoom Certificate Validation Vulnerabilities

Certificate validation helps applications verify that they are communicating with trusted systems. If these checks do not work correctly, software may accept connections that should be rejected, potentially putting sensitive communications at risk.

The two Zoom vulnerabilities involve certificate validation, but the published details do not specify the exact validation failure or the method an attacker would use. There is also no confirmation that these flaws allow attackers to steal passwords, take over accounts, or execute malicious code.

CVE-2026-108184, documented in bulletin ZSB-26021, affects certain Windows-based Zoom applications. The affected products and version ranges include:

• Zoom Workplace for Windows: Versions 7.0.0 and later in the affected range, before versions 7.2.0 or 7.1.9 in the respective release branches.
• Zoom Workplace VDI Client for Windows: Versions 7.0.11 to before 7.0.13.
• Zoom Rooms for Windows: Versions 7.0.0 to before 7.1.7.

CVE-2026-108185, documented in bulletin ZSB-26022, affects certificate validation in the My Notes feature. The affected versions include Zoom Workplace for Windows from version 7.1.5, and for macOS and Linux from version 7.0.5, within the ranges specified by Zoom.

Zoom Workplace for Android and iOS is also affected by the My Notes vulnerability, starting at version 7.0.5 and continuing before version 7.2.0.

Recommended Security Updates

Organizations and individual users should review their installed Zoom versions and apply the appropriate security updates. The required fixed version depends on the product, operating system, and release branch.

Security teams should prioritize the following actions:

• Update affected applications: Install the latest supported releases from Zoom’s official Download Center.
• Audit all deployments: Check standard Workplace clients, VDI installations, Zoom Rooms, and devices using My Notes.
• Verify updates: Confirm that affected systems have moved to fixed versions after deployment.
• Coordinate across teams: Include remote devices and systems managed by separate IT teams in the update process.
• Follow official guidance: Review Zoom’s security bulletins for additional information and remediation instructions.

Disabling My Notes should not be treated as a confirmed workaround unless Zoom explicitly recommends it.

These vulnerabilities highlight the importance of keeping collaboration software updated across an organization’s entire environment. Applying patches consistently and verifying installed versions can help reduce exposure to known security weaknesses.

The post Zoom Certificate Validation Flaw Could Expose Sensitive Data appeared first on First Hackers News.

Tracked as CVE-2026-97229, the vulnerability has a maximum CVSS score of 10.0, making it a serious security risk for organizations using vulnerable GitLab installations. The issue affects both GitLab Community Edition (CE) and Enterprise Edition (EE), with patches released on October 12, 2026.

The flaw is linked to GitLab’s CI/CD regular expression compiler. If successfully exploited, it could put sensitive data, development projects, and server operations at risk. Administrators should review the affected versions and apply the available security updates as soon as possible.

How the GitLab Vulnerability Works

The vulnerability is caused by an integer overflow in the regular expression compiler used by GitLab’s CI/CD functionality. According to the security advisory, insufficient validation of regular expressions could allow an unauthenticated attacker to trigger arbitrary code execution by submitting a specially crafted expression in a CI/CD configuration.

Regular expressions are patterns used to search, match, and validate text. GitLab uses them in various processes, including CI/CD workflows. However, improper handling of specially crafted patterns can introduce security weaknesses.

In this case, an attacker could potentially exploit the flaw to execute code on the GitLab server. The published vulnerability information indicates that exploitation does not require authentication or user interaction, although the exact conditions needed to carry out an attack have not been fully disclosed.

This makes the vulnerability particularly concerning for organizations that host their own GitLab instances. Successful exploitation could affect the confidentiality, integrity, and availability of the server and its data.

GitLab credited security researcher joaxcar for reporting the issue through its HackerOne bug bounty program. The company has not stated in the cited advisory that the vulnerability has been exploited in real-world attacks.

Affected GitLab Versions and Security Updates

The vulnerability affects specific releases of GitLab Community Edition and Enterprise Edition. Administrators should check their installed versions against the following affected ranges and upgrade to the corresponding patched releases.

• GitLab 19.2: Versions before 19.2.8
• GitLab 19.3: Versions before 19.3.4
• GitLab 19.4: Versions before 19.4.2

GitLab has released security updates to address the vulnerability. Administrators running affected self-managed installations should upgrade to the appropriate patched version without delay.

According to the release notice, GitLab.com has already been updated, while GitLab Dedicated customers do not need to take action.

The same security release also addresses additional issues, including cross-site scripting (XSS), authorization weaknesses, and a prompt-related issue affecting GitLab Duo Agent Platform. Administrators should review the complete security advisory to understand all fixes included in the update.

One additional consideration is that GitLab 19.3.4 has a known issue affecting merge request pages when the Ona integration is enabled. Administrators should review the release notes and plan their upgrades accordingly while ensuring that security updates are not overlooked.

Security Recommendations

Organizations should treat this vulnerability as a high-priority patching issue because of its maximum severity rating and potential for unauthenticated code execution.

Administrators should identify all affected GitLab instances, confirm their installed versions, and apply the appropriate security updates. They should also review GitLab’s official advisory for any additional upgrade requirements or known issues.

Security teams should monitor server logs and CI/CD configuration changes for suspicious activity. Although monitoring cannot replace patching, it can help identify unusual behavior that may require further investigation.

Organizations should also follow secure CI/CD practices, restrict unnecessary access to development infrastructure, and keep GitLab components updated to reduce exposure to future vulnerabilities.

Conclusion: CVE-2026-97229 highlights the risks that can arise from flaws in CI/CD processing. With a CVSS score of 10.0 and the potential for unauthenticated remote code execution, the vulnerability requires prompt attention from administrators running affected GitLab versions. Applying the available patches and maintaining strong security controls can help protect development environments from potential attacks.

The post GitLab Security Flaw Puts Servers at Risk of Code Execution appeared first on First Hackers News.

The vulnerability affected several Google-owned websites, including Google Developers, Firebase, Android Developers, Source Android, and Partner Android documentation. Because these websites relied on a shared platform, a single underlying security issue could potentially affect multiple services.

According to the researcher’s report, the vulnerability was reported to Google in August 2026. Google addressed the issue on October 7, 2026, and awarded Koeck $90,000 through its Vulnerability Reward Program.

The discovery highlights how mistakes in session management and data processing can create serious security risks, even in widely used developer platforms.

How the Google DevSite Flaw Exposed Sensitive Credentials

The vulnerability originated in the OAuth authentication flow used by Google DevSite. During the authentication process, the application generated a Flask session cookie containing information required to manage the OAuth flow.

Flask is a Python web framework that uses signed session cookies to protect session data against unauthorized modification. However, signing does not encrypt the contents of a cookie. Anyone who obtains it may be able to read the stored information, even though changing the contents should invalidate the signature.

During his investigation, Koeck discovered that the session cookie contained more information than expected. After decoding the compressed data, he identified a serialized OAuth flow object containing a Google OAuth client ID and client secret.

The most serious finding was that the exposed OAuth client secret was also being used as the Flask session signing key.

Normally, an attacker cannot modify a signed session cookie successfully without knowing the secret key used to sign it. However, when the signing key is exposed within the session data itself, that protection can no longer be trusted.

An attacker who obtained the relevant cookie could recover the secret, generate a valid signature, and construct a forged session that the application would accept.

This meant the problem was not limited to information disclosure. It potentially allowed attackers to control data that the application considered trustworthy, creating an opportunity to exploit other weaknesses in the authentication process.

Unsafe Python Deserialization Created a Remote Code Execution Risk

The vulnerability became significantly more dangerous because of how the DevSite application processed the OAuth flow object stored in the session.

According to the researcher’s findings, the application decoded the stored data and passed it to Python’s pickle.loads() function. The pickle module is designed to serialize and deserialize Python objects, but it is unsafe when used with untrusted or attacker-controlled data.

Unlike data-only formats, a malicious pickle object can execute Python code during deserialization. This means that an application can introduce a code execution vulnerability simply by loading a crafted object without verifying that the data is trustworthy.

In this case, the exposed Flask signing key provided a way to create a forged session that could pass the application’s signature verification. The attacker could then supply a crafted serialized object as part of the session data.

When the OAuth callback processed the forged session, the application could deserialize the attacker-controlled object and execute code on the server.

The combination of these weaknesses created a potential remote code execution chain:

• The application stored sensitive OAuth information in a client-side session cookie.
• The OAuth client secret was reused as the Flask session signing key.
• An attacker could potentially recover the key and forge a valid session.
• The application deserialized session-controlled data using Python’s pickle module.
• Processing a malicious object could trigger attacker-controlled code execution.

Koeck demonstrated the issue using a harmless time-delay payload rather than executing system commands on Google’s infrastructure. Requests containing the crafted payload reportedly experienced delays matching the time specified in the serialized object.

This proof of concept demonstrated that the server was processing the crafted object in a way that could trigger the intended behavior.

The issue was particularly concerning because the OAuth endpoint could reportedly be reached without a Google account. Combined with the shared DevSite architecture, this increased the potential exposure across several Google developer properties.

However, the findings demonstrate a potential exploitation path; they do not establish that attackers exploited the vulnerability in real-world attacks or that every affected website was successfully compromised.

Google Remediated the Vulnerability and Strengthened Session Security

Google addressed the vulnerability by making several changes to the authentication and session-management design.

According to the researcher’s report, the remediation included rotating the exposed OAuth client secrets, invalidating sessions signed with the affected secrets, separating Flask signing keys from OAuth credentials, and moving OAuth flow objects to server-side storage.

These changes addressed the main weaknesses that made the attack possible. Rotating exposed credentials reduced the risk of continued abuse, while separating signing keys from OAuth secrets prevented the same credential from serving multiple security purposes.

Moving OAuth flow objects to server-side storage also reduced the amount of sensitive information that needed to be placed in browser cookies.

The incident offers several important lessons for developers and security teams.

Keep session signing keys separate from application credentials. Secrets used to sign session cookies should be unique, securely stored, and never included in data that clients can access. Reusing one secret for multiple purposes increases the impact of a single exposure.

Avoid deserializing untrusted data with pickle. Python developers should never use pickle.loads() on data that can be influenced by browsers, external integrations, or other untrusted sources. JSON or another data-only format is generally a safer choice when combined with strict schema validation and appropriate input handling.

Keep sensitive session state on the server. Browser cookies should ideally contain only an opaque session identifier or similarly limited information. Sensitive OAuth tokens, credentials, and complex authentication objects should remain in protected server-side storage.

Review shared platforms for systemic weaknesses. A vulnerability in a common authentication component can affect multiple websites at once. Organizations should regularly assess shared libraries, authentication flows, session-management mechanisms, and credential-handling practices.

Google’s response demonstrates why security vulnerabilities involving authentication and remote code execution require careful investigation and prompt remediation. Although signed cookies can provide useful integrity protection, their security depends on keeping signing keys secret and ensuring that applications handle session data safely.

The Google DevSite incident serves as a reminder that secure authentication requires more than signing a cookie. Sensitive credentials must be protected, session data must be handled carefully, and applications must never treat potentially attacker-controlled serialized objects as safe to execute.

The post Attackers Exploit Forged Flask Sessions to Achieve RCE appeared first on First Hackers News.

The vulnerability, known as AnyPwn, affects AnyDesk Linux 8.0.2 and was fixed in version 8.0.3. Organizations using AnyDesk on Linux systems should prioritize the update and check whether the service is accessible from untrusted networks.

The flaw was discovered by Rick de Jager from the V12 security team using the V12 AI-powered security testing platform. It was initially disclosed in June as a pre-authentication, zero-click remote code execution vulnerability caused by a heap buffer overflow.

AnyDesk acknowledged the report and released version 8.0.3 shortly afterward. The public exploit was released on October 8, increasing the risk for systems that have not yet been updated.

How the AnyDesk Linux Vulnerability Works

The vulnerability is located in AnyDesk’s session protocol, which handles information exchanged when remote clients connect to the service.

In the affected version, a packet-processing function does not properly validate a value that tells the application how much data is expected. The application then performs a calculation using this value before allocating memory.

A specially crafted value can cause the calculation to overflow. As a result, AnyDesk may allocate a much smaller memory area than expected while continuing to process the data as though a much larger space had been reserved.

This can result in an out-of-bounds memory write.

In simple terms, an attacker can send specially crafted network data that causes AnyDesk to write beyond the memory area it was supposed to use. Under the right conditions, this can corrupt memory and change how the application executes code.

Researchers demonstrated that the flaw could be used to execute an attacker-controlled command through the AnyDesk service.

The impact is particularly serious because the AnyDesk Linux service normally runs with root privileges. Successful exploitation could therefore give an attacker extensive control over the affected system, including access to files, processes, accounts, and security settings.

The published exploit targets AnyDesk Linux 8.0.2 running in service mode on x86_64 systems and connects directly through TCP port 7070.

However, exploitation is not guaranteed in every situation. The exploit depends on a specific memory layout, and an unsuccessful attempt may simply cause the AnyDesk service to crash.

The researchers also investigated whether the vulnerable code could be reached through AnyDesk relay connections. While they were able to reach the relevant code path during testing, they did not demonstrate the complete root-code-execution attack through a relay. Direct exposure of TCP port 7070 therefore remains the clearest confirmed risk.

Update AnyDesk and Restrict Port 7070

Administrators should identify Linux systems running AnyDesk 8.0.2 or earlier affected builds and upgrade them to version 8.0.3 or later.

If an immediate update is not possible, organizations should reduce exposure by restricting access to TCP port 7070 using firewalls, VPN controls, and cloud security groups.

Security teams should also review affected systems for signs of suspicious activity, including:

• Unexpected root-level processes
• Unusual outbound network connections
• Suspicious AnyDesk service activity
• Unexpected changes to system files or accounts
• Connections to exposed TCP/7070 services

AnyDesk’s Linux changelog records the fix, although the original entry described the issue as a problem that could cause a crash rather than detailing its security impact.

The release of a public exploit makes this vulnerability more important for organizations that have not yet patched their Linux systems.

The key takeaway: AnyDesk is a trusted remote-access tool, but an exposed and vulnerable installation can become a direct entry point for attackers. Update to 8.0.3 or later and restrict unnecessary network access to the service.

The post Critical AnyDesk Linux Flaw Allows Root Code Execution appeared first on First Hackers News.

The vulnerability is tracked as CVE-2026-107181 and affects Telegram Desktop versions before 7.2.9. It has a CVSS 4.0 score of 8.6 (High).

Security researcher Beaksec published details of the vulnerability on October 3, 2026, with an update on October 7. VulnCheck assigned the CVE shortly afterward.

The attack relies on a specially crafted link. If the victim clicks the link from outside Telegram while the desktop application is already running, the attacker may be able to interact with Telegram’s local session data.

How the Telegram Desktop Flaw Works

The problem is related to the way Telegram Desktop processes links opened from other applications.

When Telegram is already running, a newly opened link is passed to the existing Telegram process through a local communication mechanism called inter-process communication (IPC).

The vulnerability occurs because Telegram did not properly handle a special character used to separate commands or records within this communication process.

An attacker could place the character inside a specially crafted link. Telegram could then interpret part of the link as an additional command instead of treating the entire content as normal link data.

The issue has been classified as CWE-143, which covers improper handling of record delimiters.

File Theft Could Lead to Account Takeover

The public PoC shows how the flaw could be combined with an older internal Telegram component.

According to the research, the injected command could reach a legacy helper that was originally designed for publishing releases. The component could access local files and send them through Telegram without requiring normal permission checks or confirmation from the user.

This creates a serious risk because Telegram stores local session information on the device.

If an attacker obtains the right session data, they may be able to reuse the victim’s existing Telegram login and gain access to the account.

The researchers demonstrated the attack on Windows using Telegram Desktop 6.9.3 and reported that the issue remained in versions through 7.2.8.

The attack also has some limitations:

• The malicious link needs to be opened outside Telegram.
• Links opened inside Telegram use a different processing path.
• The attack was demonstrated on Windows; the available research does not show the same attack on macOS or Linux.
• Certain automatic download and group-invitation settings can affect the attack chain.
• A browser may display a warning before opening Telegram Desktop.

These conditions are important when assessing the actual risk rather than assuming every Telegram user is automatically vulnerable.

Telegram Releases a Fix

Telegram addressed the vulnerability in September 2026.

The company fixed the issue in a development commit on September 16 and released Telegram Desktop 7.2.9 on September 17.

The changes include removing the vulnerable legacy helper, properly handling the record-separator character, and improving how different types of local messages are processed.

Users should therefore upgrade Telegram Desktop to version 7.2.9 or later.

Until the update is installed, users can reduce their exposure by:

• Avoiding unexpected links that launch Telegram Desktop.
• Disabling automatic file downloads where possible.
• Restricting who can add them to Telegram groups.
• Enabling a local Telegram passcode.
• Reviewing active Telegram sessions for anything unfamiliar.

A public PoC shows that the vulnerability can be exploited under certain conditions, but it does not by itself confirm that attackers are actively using the flaw in real-world campaigns.

The main takeaway is simple: Telegram Desktop users should update to the latest version and avoid opening suspicious links that attempt to launch the application.

The post One-Click Telegram Desktop Exploit Demonstrated in New PoC appeared first on First Hackers News.

The checklist goes beyond traditional prompt-injection testing. It covers the wider environment around an AI agent, including cloud infrastructure, identity access, connected tools, memory systems, agent-to-agent communication, and deployment pipelines.

The goal is to help security teams identify weaknesses that may exist outside the AI model itself. For example, an exposed MLflow service, accessible cloud credentials, or poor customer-data isolation could create serious security risks even without successfully attacking the underlying AI model.

Security researcher Ravi Rajput developed the checklist using ideas from the OWASP Web Security Testing Guide. It is an independent resource rather than an official OWASP checklist.

20 Areas Covered by the Checklist

The testing process is divided into several stages, starting with understanding what the AI system can access before testing how it responds to malicious instructions.

The checklist covers areas such as:

• Attack surface discovery
• AI orchestration
• Cloud identity and permissions
• Model and software supply chains
• Prompt injection
• System prompt exposure
• Unsafe output handling
• Tool and plugin security
• Excessive agent permissions
• Memory and retrieval systems
• Agent-to-agent communication
• Model Context Protocol (MCP) servers
• Privilege escalation
• Lateral movement
• Persistence
• Data theft
• Resource exhaustion
• Integrity attacks
• Voice and multimodal inputs
• Deployment and CI/CD security

This broader approach helps security teams understand what an agent can access and how an attacker could move from one component to another.

222 Tests Help Measure Real-World Risk

The checklist assigns proposed severity levels to its tests:

• 75 Critical
• 108 High
• 30 Medium
• 9 Low

These ratings represent the potential importance of each test. They do not mean that every AI system contains the associated vulnerability.

Some tests focus on cloud and infrastructure weaknesses. Others examine how connected tools can be abused to move from an apparently harmless action to unauthorized data access.

Examples include:

• Stealing cloud credentials through SSRF
• Exploiting unsafe Python pickle loading
• Combining legitimate tools to transfer data without authorization
• Accessing another customer’s documents because of missing tenant controls
• Forging messages between AI agents
• Abusing delegated privileges
• Manipulating MCP-connected tools

Memory and retrieval systems receive particular attention. One test checks whether removing or bypassing a customer identifier could expose documents belonging to another tenant.

This is important because an AI application can appear secure while its underlying data-access controls remain weak.

Evidence and Safe Testing Matter

The checklist also provides guidance on how security teams should document their findings.

Tests can produce different types of evidence:

• Reflective evidence – The system directly shows the result.
• Blind evidence – The tester relies on changes such as timing or system state.
• Out-of-band evidence – A controlled callback confirms that an action occurred.

According to the checklist, reflective and controlled callback evidence can provide stronger confirmation, while blind-only results may need further validation.

The spreadsheet also includes testing objectives, recommended steps, suggested tools, expected results, severity ratings, and evidence requirements.

Security teams are advised to define the testing scope before starting, document excluded tests, and preserve supporting logs or screenshots. Destructive tests should only be performed when explicitly authorized, preferably in controlled or staging environments.

The checklist maps its tests to OWASP and MITRE ATLAS, giving security teams a structured way to connect individual tests with broader AI security frameworks.

The main takeaway is that agentic AI security cannot be limited to testing prompts. Organizations also need to examine the infrastructure, permissions, tools, memory, data flows, and connections that allow AI agents to take real-world actions.

The post New AI Red Team Guide: 222 Security Tests Unveiled appeared first on First Hackers News.

The most serious issue is a pre-authentication server-side request forgery (SSRF) vulnerability that could allow a remote attacker to send requests through a vulnerable appliance without logging in.

SonicWall published the security advisory on October 6, 2026. The company said it has not found evidence that these vulnerabilities are currently being exploited in attacks, but recommends that customers install the available updates as soon as possible.

The affected products include physical and virtual SMA 6210, SMA 7210, and SMA 8200v appliances.

Critical SSRF Vulnerability

The most serious vulnerability is CVE-2026-102255, which affects the SMA1000 Appliance WorkPlace interface.

The flaw is caused by an unintended access path that can make the appliance operate like a proxy. An attacker could abuse this behavior to send requests through the device and potentially reach internal services that should not be directly accessible.

The attack does not require valid credentials or user interaction, making the vulnerability particularly serious.

SonicWall has classified the issue under CWE-918 (SSRF) and CWE-441 (confused deputy/unintended proxy). The vulnerability can potentially affect the confidentiality, integrity, and availability of the affected system.

Three More Vulnerabilities

SonicWall also fixed three additional security issues:

• CVE-2026-102256 – Command Injection: Rated CVSS 7.8. An authenticated administrator could potentially execute operating-system commands under specific conditions, which could result in remote code execution.
• CVE-2026-102257 – Zip Slip: Rated CVSS 7.2. A specially crafted archive could extract files outside the intended directory. SonicWall says successful exploitation could potentially lead to remote code execution.
• CVE-2026-102258 – Stored XSS: Rated CVSS 5.5. An authenticated administrator could potentially store malicious JavaScript in the Appliance Management Console (AMC), where it could later execute in another user’s browser context.

The vulnerabilities were reported by security researchers from Anthropic, Trend Micro’s Zero Day Initiative, and DigitalCanion SA.

Affected Versions and Updates

SonicWall says the affected versions include:

• 12.4.3-03526 and earlier
• 12.5.0-02952 and earlier

Customers should upgrade to:

• 12.4.3-03670 or later
• 12.5.0-03082 or later

The required fixes are available through MySonicWall. SonicWall has not provided a workaround and recommends applying the appropriate hotfix.

It is important to note that SonicWall firewalls running SSL-VPN services and the SMA 100 Series are not affected by this particular advisory.

Administrators should check the exact software build running on each SMA1000 appliance and upgrade to a fixed version. Installing an earlier September update is not enough because the versions that contained those previous fixes are also affected by the newly disclosed vulnerabilities.

The key takeaway is simple: SMA1000 administrators should verify their appliance versions and apply the latest security updates as soon as possible.

The post SonicWall SMA1000 Update Fixes Critical Security Issues appeared first on First Hackers News.