The research shows how AI can help security researchers examine large codebases and spot complicated mobile security problems. However, the findings still need to be checked and tested by human security experts.

How the AI Security Agent Works

The research used GitHub Security Lab’s Taskflow Agent, an open-source framework built to support AI-assisted security testing.

Instead of giving an AI model a huge codebase and asking it to find everything, researchers divided the investigation into smaller tasks designed specifically for Android.

One workflow looked for important Android entry points, including:

• Exported activities and services
• Broadcast receivers
• Deep links

Another workflow then checked these areas for common Android security problems, such as unsafe intents, insecure broadcasts, WebView issues, and cross-app attacks.

This approach helped the AI focus on the parts of an application that could be exposed to other apps or external input.

OsmAnd Flaw Could Reveal User Locations

One of the notable vulnerabilities was found in OsmAnd, a popular Android navigation application with more than 10 million downloads.

Researchers discovered that its exported MapActivity could accept certain attacker-controlled settings through Android intents.

A malicious app installed on the same device could use these inputs to silently change OsmAnd settings. One possible attack could redirect map-tile requests to a server controlled by the attacker.

By watching the requests, an attacker could potentially determine where a user was located and track movements. Routing information, including starting points and destinations, could also be exposed.

The concerning part is that the victim could continue using the navigation app normally without realizing anything had changed.

Wikipedia Bugs Could Lead to Account Takeover

Another serious chain was found in the Wikipedia Android app.

The application uses a wikipedia:// deep link to open content inside its WebView. Researchers found that the app used an unsafe domain check that looked at whether a hostname simply ended with wikipedia.org.

That means a domain such as evil-wikipedia.org could potentially pass the check even though it was not an official Wikipedia domain.

Researchers also identified another weakness involving cookie handling. When combined, the issues could potentially expose authentication information to an attacker-controlled webpage.

This could give an attacker access to a victim’s Wikimedia session and potentially lead to account takeover after the victim interacts with a malicious link.

AI Helps Researchers, But Humans Still Matter

GitHub emphasized that AI-generated security findings should not automatically be treated as confirmed vulnerabilities.

AI models can be useful for identifying suspicious code, APIs, and attack paths, but they can also produce false positives or misunderstand how a vulnerability behaves in a real environment.

Researchers found that asking the AI to create a proof of concept can help determine whether a suspected issue is actually exploitable. Even then, human testing remains an important part of the process.

The Taskflow Agent and the Android security workflows have been made publicly available, giving security researchers another way to use AI for structured mobile application testing.

The post GitHub AI Agent Discovers 24 Android Flaws appeared first on First Hackers News.

File-notification systems are designed to help applications know when files or folders change. However, researchers discovered that the information they provide can also reveal useful clues about what a user is doing.

The research was conducted by researchers at Graz University of Technology. Their study, titled “File Notification Attacks: Templating and Exploiting Side-Channel Leakage from the File-Notification Systems on Linux, Windows, and macOS,” explores how these signals can be used as a side channel.

How the File Notification Attack Works

Linux, Windows, and macOS use different technologies to monitor file-system changes. These include inotify on Linux, ReadDirectoryChangesW on Windows, and FSEvents on macOS.

These services are not vulnerabilities by themselves. They are legitimate features used by applications to respond to changes in files and folders.

The problem is that notifications can contain information such as file paths, timing, and activity patterns. By collecting this information and comparing it with previously recorded examples, malicious software can potentially identify what a user is doing.

Researchers created a semi-automated system that records file-system activity while different actions are performed. These recordings can then be used as templates to recognize similar activity later.

The study found that these patterns could reveal activities including terminal commands, keyboard and mouse input, website visits, printing, virtual machines, containers, VPN changes, Bluetooth activity, and USB-device connections.

The monitoring also had a very small effect on system performance, with the researchers measuring CPU overhead of no more than 0.21% in their tests.

Linux and Windows Show Significant Information Leakage

Linux produced some of the most detailed activity signals in the study. Researchers found that an unprivileged user could receive certain file notifications even when they could not directly read the related files.

This information was enough to identify keystroke patterns in testing involving seven users, with F1 scores ranging from 93.1% to 100%.

The researchers also monitored pseudo-terminal activity over SSH and achieved a 100% F1 score in their test scenario. Passwords entered into terminals with input echo disabled were not observable.

On Windows, the researchers found that monitoring the root of the C: drive could expose file paths associated with another user’s profile, even when the monitoring user did not have permission to access those directories.

Browser activity was another concern. File-system patterns created by browser storage could help identify websites visited by a user. In the study, Firefox activity from 975 of the top 1,000 tested websites could be identified, achieving a 97.8% F1 score in the researchers’ test. Edge produced fewer site-specific patterns and achieved a 48.5% F1 score.

macOS Reveals Less, But Still Exposes Activity

macOS provided stronger separation between users because FSEvents does not freely expose private directories belonging to other users.

However, researchers were still able to identify patterns associated with activities such as application launches, system setting changes, printing, network activity, external storage, Bluetooth devices, and virtual machines.

The average notification latency on macOS was around 11.48 milliseconds, making it slower than the other platforms tested. Despite this, researchers said the information could still be useful for behavioral monitoring.

Importantly, this technique is not a remote attack that can compromise a computer over the internet. Malicious software must already be running on the machine as a local, unprivileged user.

That makes the technique more relevant to post-compromise surveillance, where malware already present on a system attempts to gather additional information about the victim.

Researchers Recommend Stronger Protection

The researchers reported their findings to Linux, Microsoft, Apple, and KDE in October 2025.

Linux introduced a partial mitigation for certain device files in early 2026. Microsoft classified the behavior as being by design and provides the EnforceDirectoryChangeNotificationPermissionCheck policy to restrict certain unauthorized path disclosures. The researchers noted that this setting is disabled by default.

The researchers recommend stronger permission checks that clearly separate files a user owns, files they can read, and protected files belonging to others. They also recommend tighter controls on applications that attempt to monitor large sections of the file system.

Organizations can reduce the risk by keeping systems updated, limiting untrusted software, using application sandboxing, separating service accounts, and applying stricter notification permissions where available.

The research highlights an important security lesson: attackers do not always need to read sensitive data to learn something about a user. File paths, timing information, and system notifications can become valuable sources of intelligence when analyzed together.

The post Hackers Exploit File Notifications to Track User Activity appeared first on First Hackers News.

Instead of downloading a ready-made miner, the attackers built the mining software directly on the compromised computer. This unusual step created activity that security tools could detect.

The incident was discovered in early September 2026 during an investigation of a MagicINFO Premium system. After gaining access, the attackers installed a remote access tool, created an administrator account, disabled Microsoft Defender, and used the machine to mine Monero.

Huntress researchers found the activity while investigating a managed endpoint. The case involved one confirmed system and shows how a vulnerable internet-facing service can lead to long-term access and unauthorized use of computing resources.

Attackers Exploited a MagicINFO Vulnerability

The initial access was linked to CVE-2025-4632, a vulnerability in MagicINFO that allows attackers to write files with system-level privileges.

Samsung released a fix for the flaw in May 2025.

After the initial alert, the customer was advised to address the issue. However, investigators observed new activity eight days later through the same access route.

The attackers attempted to install AnyDesk, a legitimate remote access application, three times.

The first two attempts were blocked by Microsoft Defender. The attackers eventually succeeded and configured a password so they could reconnect to the machine.

They then created a local administrator account and disabled Microsoft Defender, giving themselves a more reliable way to maintain access.

The Miner Was Built on the Infected PC

Once the system was under their control, the attackers launched a Monero miner builder from the user’s Documents folder.

The process started several development tools and C compilers to create the mining software directly on the machine.

This approach helped the attackers avoid simply dropping a finished miner onto the system, but it also created a noticeable trail.

The unsigned builder generated unusual compiler activity that could stand out in endpoint monitoring.

Afterward, investigators observed the miner connecting to a public mining pool and using the compromised system’s computing resources.

The mining activity also appeared to involve Windows Explorer, making the behavior even more suspicious.

What Security Teams Should Watch For

The incident highlights why patching internet-facing MagicINFO installations is important.

Security teams should pay attention to:

• Unexpected remote access software
• New administrator accounts
• Microsoft Defender being disabled
• Unusual compiler activity
• Unknown processes using high CPU resources
• Unexpected connections to cryptocurrency mining pools

Removing the miner is not enough. Teams should also determine how the attacker gained access and whether the vulnerable entry point is still exposed.

The post Samsung Flaw Turns Devices Into Cryptominers appeared first on First Hackers News.

Tracked as CVE-2026-94545, the vulnerability affects the Node.js version of the ImageResponse feature in the next/og package. It can become dangerous when applications use untrusted data inside SVG images.

The issue affects Next.js 16.2.0 through versions before 16.3.6. Developers should upgrade to Next.js 16.3.6, which includes the fix.

How the Attack Can Happen

ImageResponse is commonly used to generate Open Graph images, social media previews, and other graphics directly from a Next.js application.

The problem appears when user-controlled information is placed into SVG content, attributes, or styles during image generation.

For example, an application might take information from a URL parameter, form, or API request and insert it into an SVG before generating an image.

An attacker could send specially crafted input that reaches the vulnerable image-rendering process. If the application is configured in a vulnerable way, this could result in remote code execution on the server.

The potential impact depends on the application’s permissions and what resources the server can access. A compromised environment could potentially expose sensitive information, modify content, disrupt services, or provide access to other connected systems.

Who Is Affected?

Not every Next.js application is vulnerable.

According to the provided advisory information, applications using the Edge implementation of ImageResponse are not affected.

Applications using the Node.js implementation may also be unaffected if they never place attacker-controlled data into SVG content, attributes, or CSS styles.

The vulnerability has been rated Critical and can be exploited remotely without authentication or user interaction.

Update to Next.js 16.3.6

Developers should review applications that generate images through next/og, especially Open Graph image endpoints that accept URL parameters or other external input.

The recommended action is to:

• Upgrade affected Next.js installations to 16.3.6.
• Check image-generation routes for untrusted input.
• Review SVG content, attributes, and styles that use user-controlled data.
• Avoid passing untrusted input directly into SVG processing.
• Review internet-facing image-generation endpoints.

If an immediate upgrade is not possible, removing attacker-controlled input from SVG processing can reduce the risk.

The vulnerability was reported by security researchers RaghavMaheshwari124 and rafabd1. Given that image-generation endpoints can be exposed to the internet, organizations using the affected Node.js ImageResponse implementation should review and patch their applications promptly.

The post Critical Next.js Bug Puts Applications at Risk appeared first on First Hackers News.

The email address contains a long-lived incoming-email token. GitLab documentation says this token must remain private because anyone who has it can perform actions as the token owner, including creating issues and merge requests.

The problem becomes more serious because the feature can also be used to send code changes into a repository.

A Private Email Address Can Trigger Code Changes

Aikido found that email addresses created for different projects can contain the same account-level token.

An attacker who obtains the address can reportedly change the email format from an issue address to a merge-request address and include a Git patch. By specifying a source branch in the email subject, GitLab can apply the patch using the permissions of the token owner.

This means the feature is not limited to creating unwanted issues.

For example, an attacker could modify a project’s .gitlab-ci.yml file. If the change triggers a CI/CD pipeline, attacker-controlled commands could potentially run within the victim’s project.

Depending on the user’s permissions and pipeline setup, this could expose source code, CI/CD variables, job tokens, or other sensitive information.

Network Restrictions May Not Stop It

The research also found that GitLab’s incoming email workflow can bypass assumptions about IP-based restrictions.

Aikido reported testing a private project that allowed access only from a specific IP address. While browser access and Git cloning were blocked, the emailed patch was still accepted and resulted in a commit to the main branch.

GitLab now documents that incoming email is not covered by IP restrictions, meaning an IP allowlist should not be considered a complete security control for this feature.

An attacker does not necessarily need to spoof the sender either, because GitLab does not currently require the email to come from an address verified on the token owner’s account.

What GitLab Users Should Check

GitLab has treated the behavior as part of the feature’s design rather than a traditional vulnerability. The company has nevertheless updated its interface and documentation to better explain the risks and the capabilities of incoming email addresses.

Organizations should search repositories, documentation, tickets, logs, and public pages for exposed glimt- email addresses and older incoming-mail token formats.

If an address has been exposed, the associated incoming email token should be reset, which invalidates the related project email addresses.

Security teams should also review:

• User permissions
• Protected branch settings
• CI/CD pipelines
• CI/CD variables
• Recent commits
• Audit events

The main takeaway is simple: GitLab project email addresses containing incoming-mail tokens should be treated like credentials and kept secret.

The post GitLab Flaw Lets Attackers Push Code to Private Repos appeared first on First Hackers News.

The vulnerability is tracked as CVE-2026-65660 and has a CVSS score of 8.8. It affects SharePoint Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition.

Since SharePoint environments can contain sensitive company documents and operate with powerful service accounts, a successful attack could potentially lead to credential theft, data theft, movement across the network, or continued access.

A Problem With SharePoint Security Checks

The vulnerability was discovered by Dinh Ho Anh Khoa from Viettel Cyber Security.

The issue involves SharePoint’s SafeControls protection, which is designed to prevent potentially unsafe server-side classes from being loaded while processing Web Part and page content.

The problem occurs when the ToolPane component handles specially crafted Register directives. An attacker can manipulate the way certain values are reconstructed, potentially changing the directive after SharePoint has already performed its security validation.

This can allow dangerous .NET classes to be registered and used as part of a code-execution chain.

The research demonstrated an attack chain involving XamlServices.Parse(), ExpandedWrapper, ObjectDataProvider, and LosFormatter.

The technique can also create an in-memory webshell, meaning an attacker may not need to leave a traditional webshell file on the server.

What Organizations Should Do

Microsoft released fixes for the vulnerability on August 11, 2026.

The affected SharePoint builds mentioned in the provided advisory are:

• SharePoint 2016: 16.0.5565.1001
• SharePoint 2019: 16.0.10417.20198
• SharePoint Subscription Edition: 16.0.19725.20522

Microsoft requires organizations to install all applicable update packages. SharePoint 2016 administrators may need to install both listed packages.

The research also points to a possible connection with an authentication weakness in ToolPane. Under certain configurations that allowed anonymous access, the vulnerabilities could potentially be chained to achieve pre-authentication remote code execution. The provided information says Microsoft addressed that anonymous-access route in its June 9, 2026 update.

Security teams should patch affected SharePoint servers, reduce unnecessary anonymous or internet-facing access, and review activity for suspicious Web Part requests.

During an investigation, teams should also examine IIS logs, ULS logs, Windows events, PowerShell activity, endpoint telemetry, unexpected processes, unusual assemblies, and memory activity.

SharePoint 2013 was also reportedly affected by the underlying technique, but that version reached end of support in 2023. Organizations still running it should consider migration or isolation rather than relying on a future security update.

The post SharePoint Vulnerability Enables Remote Code Execution appeared first on First Hackers News.

The vulnerability is particularly concerning because it can be exploited without authentication. An attacker who reaches a vulnerable Management Server may be able to upload and execute malicious scripts and load arbitrary Java classes.

Since these systems are used to manage security policies and collect information across enterprise networks, a successful compromise could give an attacker access to a highly privileged part of the security environment.

How the Zero-Day Works

CVE-2026-93616 involves a combination of directory traversal and unsafe file-upload behavior in the Check Point Management web service.

An attacker can manipulate file paths to make the service access files from unintended locations. According to Check Point, the vulnerability can also allow an attacker to load an arbitrary Java class without first logging in.

Check Point said it has observed a small number of targeted attacks. The company reported that the activity began before the vulnerability was publicly disclosed, which is why it is classified as a zero-day. The vendor has not publicly identified the attackers or disclosed the full objectives of the observed attacks.

Affected products include Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server and SmartEvent.

Which Versions Are Affected?

Check Point lists several affected releases, including older and currently supported versions. Administrators should check their exact release and Jumbo Hotfix level against the vendor’s advisory before deciding whether their systems are vulnerable.

Check Point says the fix is included in:

• R82.10 Take 45
• R82 Take 127
• R81.20 Take 170
• R81.10 Take 192

The company has also released an R82.20 Security Hotfix. Smart-1 Cloud is not affected because the required fix has already been applied.

What Security Teams Should Do

Organizations running affected Check Point Management products should prioritize applying the appropriate security update.

Until systems can be patched, Check Point recommends keeping Management Servers behind a Security Gateway or firewall and restricting TCP port 19009 to trusted IP addresses. Trusted Clients configured in SmartConsole should also be limited to known internal addresses.

Security teams should also review logs for signs of exploitation rather than checking only internet-facing systems. Check Point provides indicators and investigation guidance that can help identify suspicious activity.

If a vulnerable Management Server shows signs of compromise, teams should preserve relevant logs and forensic data, investigate activity that occurred after the initial access, and contact Check Point Support.

The active exploitation of this vulnerability shows why management infrastructure deserves the same patching priority as internet-facing security appliances. A compromised management server can potentially provide an attacker with access to a central administrative layer of an organization’s security environment.

The post Active Attacks Target Check Point 0-Day appeared first on First Hackers News.

The new versions are:

• Windows: 153.0.8010.52/.53
• macOS: 153.0.8010.52/.53
• Linux: 153.0.8010.52

The two most serious vulnerabilities affect Chrome’s graphics technologies and could potentially allow malicious web content to cause memory corruption.

Critical Dawn and WebGL Vulnerabilities

The most serious issue is CVE-2026-93374, a critical use-after-free vulnerability in Dawn, Chrome’s implementation of the WebGPU graphics API.

A use-after-free occurs when software continues to access memory after that memory has already been released. In a browser, successful exploitation could potentially cause crashes, memory corruption, or arbitrary code execution through a specially crafted website or web application.

Security researcher Florian Schweitzer reported the Dawn vulnerability to Google on April 8, 2026. Google has not disclosed the reward associated with the report.

Chrome 153 also fixes CVE-2026-93372, a critical buffer overflow in WebGL. WebGL allows websites to display interactive 2D and 3D graphics directly in the browser.

A buffer overflow happens when a program writes more data into a memory area than it was designed to hold. An attacker could potentially use this to overwrite nearby memory and influence program execution.

Google’s internal security team reported the WebGL vulnerability on August 17, 2026.

Google has not published detailed technical information about either critical flaw. Keeping those details private gives users and organizations time to install the security update before information that could assist exploitation becomes widely available.

High-Severity Chrome Bugs

Chrome 153 also addresses eight high-severity vulnerabilities across several browser components.

The high-severity issues include:

• CVE-2026-93375 — Incorrect reference resolution in Tracing
• CVE-2026-93382 — Use-after-free in PDFium
• CVE-2026-93387 — Improper state validation in Skia
• CVE-2026-93373 — Use-after-free in Extensions
• CVE-2026-93381 — Buffer overflow in PDFium
• CVE-2026-93379 — Authorization flaw in ORB
• CVE-2026-93377 — Type confusion in V8

The V8 issue is particularly important because V8 is Chrome’s JavaScript engine and processes code from websites.

A type confusion vulnerability can cause the browser to incorrectly treat one type of object as another. Under the right conditions, this can lead to memory corruption and potentially become part of a larger browser exploitation chain.

Medium and Low-Severity Fixes

The remaining vulnerabilities affect several other Chrome components.

These include:

These bugs include race conditions, server-side request forgery, information disclosure, out-of-bounds memory reads, authorization weaknesses, and a user-interface spoofing issue.

Google said it will continue restricting technical details and related links until a large portion of Chrome users have installed the update. Some information may also remain restricted when affected third-party libraries are used by other projects that have not yet released their own fixes.

Update Chrome Now

Users should update Chrome as soon as possible.

To manually check for the update:

1. Open Chrome.
2. Select the three-dot menu.
3. Go to Help → About Google Chrome.
4. Allow Chrome to download and install the update.
5. Restart the browser when prompted.

Chrome normally updates automatically, but the browser must be restarted before a downloaded security update becomes active.

For organizations, deploying the update across managed endpoints should be a priority. Browser vulnerabilities can be triggered during everyday activities such as visiting malicious websites, opening phishing pages, viewing compromised legitimate websites, or encountering malicious advertising.

Keeping browsers fully patched is therefore an important part of endpoint security and helps reduce the opportunity for attackers to turn a simple web visit into a security incident.

The post Chrome 153 Fixes 16 Security Vulnerabilities appeared first on First Hackers News.

The flaws affect several networking components that have been part of the Linux kernel for years. They are known as DirtyAH6, TUNderflow, PPPoEject, and DiagSpill and are tracked as:

• CVE-2026-80844 — DirtyAH6
• CVE-2026-81000 — TUNderflow
• CVE-2026-68121 — PPPoEject
• CVE-2026-74469 — DiagSpill

Upstream fixes are now available for the affected kernel code.

DirtyAH6: IPv6 Memory Handling Bug

DirtyAH6 affects Linux IPsec/XFRM code responsible for processing IPv6 Authentication Headers.

The problem occurs when specially crafted IPv6 routing-header values are processed without properly checking the segments_left field. This can cause the kernel to use an invalid memory location and perform an out-of-bounds operation.

The main concern is local privilege escalation, particularly on systems where an attacker can create or control network namespaces.

In certain configurations, IPv6 routers or gateways using Authentication Header transport mode could also face a denial-of-service condition.

Researchers demonstrated root access in a controlled laboratory environment, although carrying out the same technique remotely was described as difficult.

TUNderflow Targets Virtual Networking

TUNderflow affects the Linux TUN/TAP virtual networking subsystem.

A local attacker can potentially provide unusually large receive-headroom values through certain network-device configurations, including paths involving Open vSwitch.

This can trigger an integer underflow while the kernel allocates a socket buffer. As a result, packet data may be placed outside the expected memory area, creating opportunities for out-of-bounds reads and writes.

PPPoEject Creates a Use-After-Free

PPPoEject affects Linux’s PPP-over-Ethernet implementation.

The vulnerability occurs because pppoe_sendmsg() can retain a pointer to a PPPoE header while another function modifies the underlying socket buffer.

If that buffer is reallocated, the original pointer becomes invalid. Subsequent operations using the stale pointer can then modify memory that has already been freed.

The upstream fix addresses the issue by retrieving the header pointer again after the device-header operation completes.

DiagSpill Can Corrupt Kernel Memory

DiagSpill affects SCTP diagnostic processing through sock_diag.

The vulnerability is related to a mismatch between the maximum number of SCTP peer transports and the size of the counter used to track them.

When the counter reaches its limit, it can wrap around to zero. The kernel may then allocate too little space before copying peer information, potentially causing data to be written beyond the allocated Netlink response buffer.

Unlike the other three vulnerabilities, DiagSpill does not require unprivileged user namespaces or special capabilities when SCTP and sctp_diag are enabled.

Remote crash scenarios may also be possible when certain SCTP address-configuration features are active, although those features are disabled by default.

Linux Kernel Updates Available

The vulnerabilities were reported to the Linux kernel security team in July, and fixes have now been released through the coordinated disclosure process.

The stable kernel releases containing fixes for all four vulnerabilities include:

• Linux 5.10.270
• Linux 5.15.221
• Linux 6.1.188
• Linux 6.6.157
• Linux 6.12.109
• Linux 6.18.50
• Linux 7.2.4

Administrators should update affected systems to a kernel version containing the fixes.

If an immediate update is not possible, organizations can reduce exposure by restricting unprivileged user namespaces and disabling networking features that are not required, such as AH6, TUN/TAP, PPPoE, SCTP, or sctp_diag.

These workarounds provide only partial protection. In particular, disabling user namespaces does not prevent DiagSpill, so applying the appropriate kernel security updates remains the primary mitigation.

The post Four Linux Kernel Flaws Could Enable Root Access appeared first on First Hackers News.

The vulnerability has a CVSS score of 9.8, making it a high-priority issue. It can be exploited remotely without user interaction or existing privileges.

The problem occurs during the login process. An attacker can submit an unusually long username, causing a stack overflow before authentication is completed.

If successfully exploited, the attacker could gain complete control of the affected system and potentially access management information, security policies, administrator details, and stored logs.

Affected Check Point Products

The vulnerability affects several Check Point management and logging products, including:

• Security Management Server
• Multi-Domain Security Management Server
• Log Server
• Multi-Domain Log Server

Affected releases include R82.20, older builds of R82.10, R82, R81.20, and unsupported R81.10, R80, R80.40, and R81 versions.

Check Point says Smart-1 Cloud is not affected, as the fix has already been applied to that environment.

Check Point has not reported active exploitation or publicly disclosed technical details of an exploit.

What Security Teams Should Do

Organizations should treat this vulnerability as an urgent patching priority.

Security teams should check SmartConsole Audit and Admin login records for:

“Administrator failed to log in: Username too long.”

This could indicate an attempted exploit, but the surrounding activity should be reviewed before confirming compromise.

Check Point has distributed the fix through Check Point LivePatch. Organizations using automatic security updates should still verify that the patch is active on every affected management and logging server.

Administrators can check the LivePatch status from Expert mode using:

cplp list

The affected systems should show the fwm patch as armed and running in livepatch mode, with CVE-2026-91843 listed in the patch details.

Until patching is confirmed, organizations should also limit SmartConsole Trusted Clients to known and approved IP addresses or subnets.

Because this vulnerability can provide root access without authentication, organizations should prioritize exposed and unsupported Check Point management systems and move to supported releases as part of remediation.

The post Check Point Vulnerability Allows Remote Root Access appeared first on First Hackers News.