According to research from Acronis’ Threat Research Unit, this ransomware can interfere with Microsoft Defender, disrupt backup operations, and remove recovery data from compromised Windows computers. These actions can leave organizations with fewer options when trying to restore their systems.

The operation also uses double extortion, meaning victims may face both encrypted files and the threat of stolen information being exposed.

A Ransomware Attack Designed to Disrupt Recovery

Many ransomware incidents begin with unauthorized access. Once inside a network, attackers may try to weaken security controls before launching the main attack.

The Gentlemen ransomware uses several techniques to achieve this. Rather than focusing only on encrypting documents, it attempts to interfere with multiple parts of the affected environment.

Its activities can include:

• Tampering with Microsoft Defender settings to reduce malware detection.
• Stopping services used by backup platforms, databases, and virtual machines.
• Removing Windows Volume Shadow Copies that may help restore previous file versions.
• Clearing selected system records that could help investigators reconstruct the incident.
• Establishing persistence so the malware can continue operating on an infected computer.

These actions can turn a malware infection into a wider business disruption. If backup operations are interrupted and recovery copies are removed, restoring affected systems may become more complicated.

How the Threat Can Reach More Computers

The risk can extend beyond the first infected machine. Acronis reports that The Gentlemen can search for connected storage and network shares, and it has capabilities for spreading across Windows environments.

When the relevant feature is enabled, the malware can identify a Windows domain and use PsExec to execute its payload on other workstations. PsExec is a legitimate administration utility, but attackers can misuse it to run programs remotely.

The ransomware may also use scheduled tasks and Windows startup registry entries to maintain persistence.

This makes monitoring activity between computers particularly important. Unexpected remote execution, unusual administrative access, or security services stopping across several devices could indicate that an intrusion is spreading.

Vulnerable Drivers Add Another Layer of Risk

The research also describes a separate tool that abuses vulnerable Windows drivers to interfere with security processes.

This approach is commonly called Bring Your Own Vulnerable Driver (BYOVD). Instead of relying only on ordinary applications, attackers exploit weaknesses in drivers that operate with elevated system privileges.

Acronis identified references to Safetica ProcessMonitorDriver and Lenovo BootRepair.sys in its analysis.

Once security tools are disrupted, ransomware may have a better opportunity to carry out malicious activity. Organizations should therefore monitor unexpected driver installations and investigate attempts to terminate endpoint protection processes.

What Happens to Files During an Attack?

The Gentlemen ransomware uses ChaCha20 encryption to lock files and elliptic-curve cryptography to protect the associated encryption keys, according to the technical report.

The malware can encrypt smaller files in full and larger files in sections. It also changes file extensions and leaves ransom notes in affected directories.

However, encryption is only one part of the threat. The group’s double-extortion approach creates a separate risk: stolen business information could be exposed even if an organization manages to recover its files.

Acronis describes the operation as a ransomware-as-a-service group that emerged in 2025 and targets multiple platforms, including Windows, Linux, network-attached storage, and BSD systems. The group has claimed more than 800 victims, although that figure has not been independently verified.

Steps Security Teams Should Take

Organizations should focus on detecting suspicious behavior early and ensuring that compromised computers cannot easily reach or destroy recovery systems.

Recommended defensive measures include:

• Monitor endpoint protection: Alert on unexpected changes to Defender settings, exclusions, and security services.
• Separate backup infrastructure: Use immutable or offline copies and restrict access from ordinary user and server accounts.
• Limit administrator privileges: Reduce the number of accounts that can install drivers or execute programs remotely.
• Watch for lateral movement: Investigate unusual PsExec activity, suspicious PowerShell commands, and unexpected connections between workstations.
• Review system integrity: Investigate unexplained log clearing, driver installations, and sudden changes to large numbers of files.
• Test recovery plans: Confirm that critical systems can be restored from clean, verified backups.

If an attack is suspected, isolate affected systems where feasible and follow the organization’s incident response process. Preserve available evidence and verify that backup environments remain safe before beginning recovery.

Final Thoughts

The Gentlemen ransomware illustrates why ransomware defense must cover more than file encryption. Security tools, administrator accounts, network connections, and backup infrastructure can all become targets during an intrusion.

Organizations that monitor suspicious system changes and keep recovery copies isolated have a better chance of limiting the impact of an attack.

IoCs

The post Gentlemen Ransomware Attacks Windows Systems and Targets Backup Recovery appeared first on First Hackers News.

Announced on October 20, 2026, the new protection is available to users who enable Enhanced Protection in Chrome’s Safe Browsing settings.

The update builds on Google’s earlier use of Gemini AI to identify technical support scams on supported devices. By using a more powerful server-side model, Chrome can analyze a wider range of suspicious websites and help users avoid online threats.

How Gemini AI Identifies Online Scams

Fake antivirus alerts and browser update messages often trick users into believing their devices are infected or out of date. These pages may encourage visitors to download malicious software, share sensitive information, or follow dangerous instructions.

Chrome’s new Gemini model examines suspicious webpage content to understand what the site is trying to do. It assesses the page’s purpose and generates a score indicating how likely it is to be a scam.

Chrome combines this analysis with domain reputation and other security signals before deciding whether to display a warning.

Google says server-side analysis is limited to webpage text that already shows strong signs of a scam. The content processed for this purpose is not logged, retained, or used to train AI models.

This approach helps Chrome investigate suspicious pages while limiting the information processed.

New Warnings and Protection Against ClickFix Attacks

Google is also improving how Chrome warns users about potentially dangerous websites.

The browser will distinguish between two types of warnings:

• Suspicious websites: Pages showing deceptive behavior that may indicate a scam, but where the evidence is less certain.
• Dangerous websites: Pages identified as posing a high risk to users, which trigger Chrome’s familiar full-page red warning.

This distinction helps users understand the level of risk before continuing to a website.

Chrome is also strengthening its defenses against ClickFix attacks, a technique in which scammers trick people into running commands on their computers by pretending to help them fix a technical problem.

These attacks may instruct users to copy commands into Windows tools such as PowerShell or Command Prompt. Running those commands can download or execute malware, potentially bypassing normal browser download protections.

Chrome can now detect potentially malicious commands copied during suspected ClickFix activity. Before sending clipboard content to Safe Browsing for analysis, it removes personally identifiable information.

If the system identifies a dangerous command, Chrome displays a warning. Google says the detection system is designed to prioritize accuracy and reduce unnecessary interruptions for legitimate users, including developers.

How to Enable Chrome’s Enhanced Protection

These new defenses require Enhanced Protection to be enabled in Chrome.

Users can check the setting by following these steps:

1. Open Google Chrome.
2. Click the three-dot menu and select Settings.
3. Open Privacy and security.
4. Select Safe Browsing.
5. Choose Enhanced protection.

Enhanced Protection provides additional safeguards against dangerous websites, downloads, and online scams.

Google describes this mode as offering substantially more protection than Standard Protection. However, its claim that users are “ten times safer” refers to the average number of security warnings received across protection modes, not a proven tenfold reduction in successful cyberattacks.

As online scams become more convincing, AI-based detection can provide another layer of defense. Users should still avoid running unfamiliar commands, downloading software from untrusted websites, or following unexpected security alerts.

Conclusion: Google’s Gemini-powered security improvements aim to help Chrome users recognize deceptive websites and dangerous commands before they cause harm. Enabling Enhanced Protection and staying alert to suspicious instructions can help reduce the risk of online scams.

The post Google Chrome Enhances Scam Protection with Gemini AI appeared first on First Hackers News.

Tracked as CVE-2026-0257, the flaw affects certain PAN-OS and Prisma Access configurations. Attackers may bypass normal login protections, including multi-factor authentication (MFA), and establish unauthorized VPN connections.

In an October 19, 2026, update, Palo Alto Networks Unit 42 linked exploitation attempts to ransomware groups known as Qilin and Inc. Public reporting has also associated attacks with Settra ransomware. <Cite refs={[“turn898104view0″,”turn898104view1”]}/>

How the VPN Attack Works

The vulnerability involves the way GlobalProtect handles authentication override cookies. These cookies allow users to reconnect without completing the full authentication process each time.

Certain vulnerable configurations may accept forged cookies, allowing attackers to bypass normal authentication checks. Exposure depends on the device configuration, including the use of authentication override cookies and a specific certificate setup. <Cite refs={[“turn898104view1”]}/>

Once attackers gain access, they may attempt to move deeper into the network and prepare for further attacks.

Researchers reported the following activities:

• Using remote monitoring tools to explore internal networks.
• Moving between systems through Remote Desktop Protocol (RDP) and Server Message Block (SMB).
• Preparing tools to collect credentials and steal data.
• Targeting virtualization and backup infrastructure.

In one investigated case, attackers reached VMware vCenter and accessed a domain controller’s virtual disk to extract credentials offline. This technique can bypass security tools operating inside the affected virtual machine.

Researchers also observed activity involving Veeam backup infrastructure, highlighting the risk to systems organizations rely on to recover from ransomware attacks. <Cite refs={[“turn898104view0”]}/>

How Organizations Can Protect Their Networks

Palo Alto Networks has rated the vulnerability High severity, with a CVSS score of 7.8, and recommends urgent action for affected deployments. <Cite refs={[“turn898104view1”]}/>

Security teams should take these steps:

• Install security updates: Upgrade affected PAN-OS and Prisma Access deployments to the fixed versions listed in the official security advisory.
• Review authentication settings: Disable authentication override if it is not required, or use a dedicated certificate exclusively for authentication override cookies.
• Check VPN logs: Investigate successful gateway-connected events associated with suspicious IP addresses, device names, or host identifiers.
• Inspect internal activity: Look for unusual RDP and SMB connections, unexpected access to vCenter, and suspicious credential access.
• Protect backup systems: Review Veeam and other backup infrastructure for unauthorized access or unusual activity.

Unit 42 has published indicators to help defenders investigate suspicious VPN connections. Its report notes that many observed probes did not establish successful VPN sessions, so security teams should focus on confirmed connections and investigate them promptly. <Cite refs={[“turn898104view0”]}/>

Final takeaway: A VPN is a critical entry point into an organization’s network. Regular patching, secure authentication settings, and monitoring for suspicious activity are essential to preventing unauthorized access and limiting the impact of ransomware attacks.

The post Palo Alto VPN Flaw Puts Credentials at Risk appeared first on First Hackers News.

The flaw, tracked as CVE-2026-108097, affects the Field UI module in Drupal core. The Drupal Security Team published the advisory on October 14, 2026.

According to the official Drupal security advisory, the issue received a risk score of 19 out of 25 under Drupal’s own rating system. It is not a CVSS score.

If exploited, the vulnerability could allow attackers to access private website data, modify content, or delete information.

How the Drupal Vulnerability Works

The vulnerability affects Drupal’s Field UI module, which helps administrators manage fields on their websites.

Drupal core alone does not provide a direct way to exploit this issue. However, the security team has confirmed that certain contributed modules and custom website code can create attack paths.

The main concerns include:

• No login required: At least one known attack path can be used without an account.
• Private data exposure: Attackers could potentially access sensitive website information.
• Website changes: Successful exploitation could allow data to be modified or deleted.
• Extensions and custom code: Additional modules or custom development may increase exposure.

The advisory does not identify all the modules involved or provide a public working exploit. Although exploitation is described as theoretical, website administrators should still take the warning seriously.

Which Drupal Versions Are Affected?

The vulnerability affects several Drupal versions, including:

• Drupal 10.6 versions earlier than 10.6.19.
• Drupal 11.3 versions earlier than 11.3.19.
• Drupal 11.4 versions earlier than 11.4.10.
• Drupal 12 development releases from 12.0.0-alpha1 up to, but not including, 12.0.0-beta2.

Older Drupal branches, including Drupal 8, Drupal 9, Drupal 10.5 and earlier, and Drupal 11.2 and earlier, are no longer covered by security support.

Administrators should check all their Drupal installations and identify any unsupported versions that may need a migration plan.

How to Protect Your Drupal Website

Website administrators should apply the appropriate security update as soon as possible.

Recommended actions include:

• Update Drupal: Install Drupal 10.6.19, 11.3.19, or 11.4.10, as appropriate for your supported branch.
• Temporarily disable Field UI: If an immediate update is not possible, uninstall the core field_ui module as advised by Drupal.
• Review contributed modules: Check installed extensions and custom code for potentially exposed functionality.
• Review website activity: Investigate suspicious changes, unexpected access, or unfamiliar scripts.
• Do not rely only on filtering: Drupal Steward can block some known attack paths, but it does not cover every possible exploitation method.

Organizations should prioritize patching and verify that every deployed Drupal website is protected. For additional investigation guidance, see our article on detecting and investigating webshells.

The bottom line: Updating Drupal to a fixed version is the recommended long-term solution. If an update must be delayed, disabling Field UI can provide a temporary mitigation while the upgrade is prepared.

The post Severe Drupal Vulnerability Puts Websites at Risk 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.

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.