Tenable Nessus: SQLi flaws to fix without delay

The CERT-FR advisory published on June 26, 2026 reports multiple vulnerabilities in Tenable Nessus, including SQL injection flaws affecting the vulnerability management platform. The issue deserves immediate attention for one simple reason: when a security tool itself becomes an attack surface, the risk is not limited to local unavailability. It also affects the integrity of scan results, the confidentiality of the data collected by the tool, and potentially the trust placed in remediation decisions made from its reports.

The paradox is well known to security and operations teams: a vulnerability scanner often concentrates highly sensitive information. Asset inventory, detection results, technical credentials depending on usage, implicit network topology, scan histories, sometimes tickets or exports sent to other tools: a compromise of a Nessus console can therefore give an attacker a privileged view of the information system. In the present case, CERT-FR mentions SQL injection vulnerabilities in Tenable Nessus. The theoretical and operational impact includes data compromise, result alteration, and a possible pivot through the security tool.

At this stage, the central point for administrators, DevOps teams, scan platform operators, and CISOs is to verify the exposure of the Nessus console, precisely identify the deployed version, then apply the fixed version published by the vendor according to Tenable’s official guidance. CERT-FR is the reference alert source here for French-speaking audiences, and the vendor advisory remains the source to follow for exact version numbers, update procedures, and any additional notes on exploitation conditions.

CERT-FR should not be read as a simple routine alert. For a CISO, the question is not only “is the Nessus server vulnerable?” but also “can we still trust the data it produces if we delay patching?”. For an administrator, the practical priority is twofold: reduce the network exposure of the console and update quickly. For an operations manager at a hosting provider or in a shared environment, especially with players such as OVH, Scaleway, or o2switch when administration consoles are exposed on shared or insufficiently segmented administration networks, it is also necessary to verify that the interface is not accessible beyond the strictly necessary perimeter.

The exact CVSS score, CVE identifiers, and detailed list of affected versions must be taken from the vendor’s official advisory and CERT-FR. When these elements are published, they should guide patching prioritization just as much as the instance’s actual exposure. In the absence of further detail in the brief editorial provided here, it is necessary to remain strictly aligned with the official documentation: multiple vulnerabilities, including SQLi, affect Tenable Nessus, and vendor fixes are available.

Reference source: the CERT-FR advisory “Multiple vulnerabilities in Tenable Nessus” dated June 26, 2026, as well as the associated official Tenable advisory cited by CERT-FR.

Affected versions

CERT-FR indicates that Tenable Nessus products are affected by multiple vulnerabilities. The precise list of vulnerable versions and the fixed version or versions must be checked in the official Tenable advisory referenced by CERT-FR, because that is the normative source for the exact scope.

• Affected product: Tenable Nessus
• Nature of the reported flaws: multiple vulnerabilities, including SQL injections
• French-language source: CERT-FR, advisory of June 26, 2026
• Vulnerable versions: refer to the list published by the vendor in the associated advisory
• Fixed version: apply the fixed version published by the vendor
• CVE: refer to the CVE identifiers indicated in the official Tenable advisory and repeated by CERT-FR
• CVSS: use the officially published CVSS score or scores to prioritize remediation

This caution is not cosmetic. In application security, an error in a version number or CVE identifier can lead to a false sense of security, incomplete patching, or incorrect compliance checks. The best practice is therefore to:

• identify the exact installed version of Nessus;
• compare it with the vendor’s version matrix;
• document the exposed scope: local console, access via reverse proxy, VPN access, Internet access;
• plan the update to the fixed version published by Tenable;
• keep a validation record after the update.

In the field, several Nessus deployment models exist: an isolated instance for internal use, a scanner attached to a SOC team, a deployment in an administration DMZ, or occasional use in testing and preproduction environments. In all cases, the version must be checked on every affected node, and not only on the most visible console.

For organizations that manage several scanners or several environments, it is useful to produce a simple inventory table:

• instance name;
• software version;
• host OS;
• network exposure mode;
• technical owner;
• date of last update;
• presence of a reverse proxy or access filtering;
• possible presence of federated or local authentication.

This work is particularly important if the tool is hosted on virtualized infrastructure or by a service provider. In an outsourced hosting context, the customer team generally remains responsible for applying application patches to its Nessus instance, even if the underlying infrastructure is administered by a third party.

Attack vector

The vector highlighted by CERT-FR is an SQL injection on the vulnerability management platform. Without repeating details not confirmed by the vendor advisory, it is worth recalling the general operation of this class of flaw to assess the concrete risks.

An SQL injection appears when an application builds a query to a database from user input that is insufficiently controlled or not parameterized. If data from an HTTP request, an API parameter, a form, a header, or a search mechanism is concatenated directly into an SQL query, an attacker may try to alter its logic. Depending on the context, this may allow:

• reading unintended data;
• modifying or deleting records;
• bypassing certain application controls;
• triggering errors that reveal the application’s internal structure;
• in some cases, obtaining broader execution depending on the privileges of the database engine or the application.

In the case of a tool like Nessus, the impact goes beyond a simple data leak. The application database may contain elements that are decisive for operating the platform:

• scan results and histories;
• scan policy definitions;
• target configuration;
• inventory metadata;
• application logs;
• local accounts or authentication-related settings depending on the configuration;
• information allowing more detailed mapping of the internal network.

The risk of integrity alteration is central here. If an attacker manages to manipulate results, delete entries, modify configurations, or distort scan policies, the organization may make security decisions on an incorrect basis. This can result in:

• real vulnerabilities hidden in reports;
• false positives injected to divert team attention;
• scan targets modified or deleted;
• scan frequencies altered;
• exports or dashboards becoming unreliable.

For a CISO, this is one of the most sensitive aspects of this alert. A compromised security tool can become a blind spot. The organization believes it is correctly observing its exposure while the source of truth is degraded. This risk is often underestimated compared with the sole notion of data leakage.

Concrete attack scenarios

Without producing a proof of concept or speculating on the exact entry point not documented here, several realistic scenarios follow from an SQLi on an administration console of this type.

• Scenario 1: console exposed to the Internet or through insufficient filtering
  An attacker discovers a publicly accessible Nessus interface, directly or behind a misconfigured reverse proxy. They attempt to exploit the SQL injection flaw through a vulnerable entry point. If exploitation succeeds, they may extract configuration data, scan results, or manipulate certain information stored by the application.
• Scenario 2: access from an overly broad administration network
  The console is not exposed to the Internet, but it is accessible from an administration network shared with many workstations or bastions. A prior compromise of an internal workstation is then enough to provide a path to the Nessus interface. The flaw becomes a risk multiplier in an internal attack chain.
• Scenario 3: discreet alteration of results
  The goal is not to steal data but to degrade trust in scans. An attacker modifies results, deletes traces of vulnerabilities on certain assets, or disrupts scan scheduling. The intended effect is stealthy persistence in the information system, not necessarily destruction.
• Scenario 4: pivot from the security tool
  Once the platform is compromised, the attacker exploits the visibility provided by the tool to better map the information system, identify network segments, sensitive hosts, deployed technologies, and defense priorities. Even without code execution on the host, the platform’s informational value may be enough to prepare a later phase.

Why an SQLi on a scanning tool is particularly critical

In many business applications, an SQL injection primarily exposes data local to the application. On a tool like Nessus, the compromised data has strategic value. It can reveal:

• which servers are the most critical;
• which weaknesses are already known to defenders;
• which patches are missing on which assets;
• which network segments are scanned regularly;
• which systems appear less monitored;
• which maintenance windows implicitly exist.

In other words, compromising the tool does not only provide technical access; it provides defensive intelligence about the organization. For an attacker, that is a considerable time saver.

This point must also be integrated into regulatory or contractual risk analyses. If vulnerability reports contain information about customers, production environments, internal addresses, or exposed components, the incident may have consequences in terms of internal notification, crisis management, and relationships with third parties.

Impact

The impact mentioned in the editorial brief is clear: data compromise, result alteration, and pivot through the security tool. These three dimensions must be treated separately to properly prioritize remediation.

Confidentiality

A successful exploitation may expose data stored by the platform. Depending on the configuration and actual use of the instance, this may include scan results, inventory information, policy settings, logs, or other sensitive metadata. The criticality depends directly on the content and segmentation of the instance.

Integrity

This is often the most underestimated risk. If results or scan settings can be modified through exploitation, the organization may lose trust in the tool itself. This loss of integrity has cascading effects:

• patching prioritization based on altered data;
• delay in fixing vulnerabilities that are actually present;
• inaccurate compliance reporting;
• incorrect view of the attack surface;
• difficulty distinguishing an outage from malicious manipulation.

Availability

Even if the alert focuses on SQLi, exploitation may also disrupt the platform’s operation: application errors, logical corruption of certain data, blocked processing, or degraded scanning and reporting capabilities. For a team that depends heavily on Nessus for its day-to-day operations, the operational effect may be significant.

Pivot risk

A vulnerability scanner is often located in a privileged administration zone. It communicates with many assets and sometimes benefits from broader network visibility than a standard workstation. Even without assuming code execution not documented here, the mere logical compromise of the platform can help prepare lateral movement, select targets, or understand which machines are the most profitable to attack.

CISO watch point: the question is not only “can an attacker read data?” but also “can they distort our measuring instruments?”. When a security tool loses its integrity, the organization loses part of its decision-making capacity.

How to patch

The priority remediation is to update Tenable Nessus to the fixed version published by the vendor. CERT-FR refers to the official Tenable advisory, which must be used as the source of truth for the exact target version and any update prerequisites.

As commands vary depending on the operating system and deployment mode, you must first identify:

• the host distribution;
• the installation mode of the Nessus package;
• the possible presence of a vendor repository;
• service restart constraints;
• the available maintenance window.

Check the installed version

Before taking any action, record the current version installed on each affected instance. Depending on the environment, this may be done through the administration interface or through a local command. The exact paths and binaries depend on the vendor’s packaging.

# Example of local verification depending on the installation
/opt/nessus/sbin/nessuscli -v

This command is given as a common example for a local Nessus deployment; it must be confirmed on your instance according to the current Tenable documentation.

Update on Debian/Ubuntu-type systems

If the instance is installed via an OS-appropriate package and a vendor repository or package is used, the update is performed by installing the fixed version published by Tenable. In practice, the operation may resemble installing a new .deb package provided by the vendor.

# Generic example if you have the vendor package
sudo dpkg -i Nessus-<fixed_version>-debian10_amd64.deb

The exact file name depends on the Tenable release. You must use the package corresponding to your distribution and deployed architecture.

If your organization maintains an internal repository or package mirror, the update can also be orchestrated through your usual configuration management tools, after validation of the fixed package.

Update on RHEL, Rocky Linux, AlmaLinux, CentOS-type systems

On RPM distributions, the principle remains identical: install the fixed version provided by the vendor.

# Generic example with a downloaded RPM package
sudo rpm -Uvh Nessus-<fixed_version>-es8.x86_64.rpm

Here again, the exact file naming and OS compatibility must be checked in the official Tenable documentation.

Restart and validation

After the update, verify the service status and that the fixed version is correctly reported.

# Check service status
sudo systemctl status nessusd

# Restart if necessary
sudo systemctl restart nessusd

Then check the version again:

/opt/nessus/sbin/nessuscli -v

Finally, log in to the console and validate the following points:

• the displayed version does indeed match the fixed version;
• the scan policies are present;
• the scheduled scans are intact;
• the histories and dashboards are consistent;
• any external integrations still work.

Governance measures around the patch

For CISO and operations teams, the patch must not be treated as a simple system operation. It is also necessary to:

• document the remediation date;
• keep proof of the version before and after;
• assess whether the console was exposed during the vulnerability period;
• plan an integrity review of recent results if the exposure was significant;
• update the inventory of critical security tools.

In industrialized environments, it is relevant to track Nessus at the same level as other sensitive administration components: bastions, virtualization consoles, orchestrators, backup tools, and monitoring solutions.

Mitigation

If an immediate update is not possible, the attack surface must be reduced as quickly as possible. These measures do not replace the patch, but they can reduce the risk of opportunistic exploitation.

Restrict network exposure

The first measure is to limit access to the Nessus console to only the strictly necessary networks and workstations.

• remove any direct Internet exposure if it exists;
• restrict access to a VPN or an administration bastion;
• filter by source addresses on the firewall;
• disable unnecessary publishing through a reverse proxy;
• segment the administration network.

Generic example of restriction with iptables on the administration port, to be adapted to your context:

# Allow only an administration subnet
sudo iptables -A INPUT -p tcp --dport 8834 -s 10.0.10.0/24 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8834 -j DROP

The exact port and rules must be validated according to your architecture and security policy.

Strengthen access control

If the console remains accessible, reduce the number of authorized accounts and verify the authentication mechanisms:

• disable unused accounts;
• enforce the use of named accounts;
• restrict access via MFA if available in your context;
• check local administrator accounts;
• review active and recent sessions.

Reduce application exposure paths

If a reverse proxy publishes the interface, verify that it does not add unnecessary exposure:

• no access from untrusted networks;
• no publishing on unnecessary public DNS names;
• logging enabled on the proxy side;
• rate limiting if it fits your policy;
• monitoring of unusual application errors.

Monitor result integrity

Because the risk of alteration is significant, unusual changes in scan data must be monitored:

• sudden disappearance of many vulnerabilities without a correlated patching campaign;
• unexpected modification of scan policies;
• deletion of targets or folders;
• creation of accounts or unplanned role changes;
• unusual export volumes.

A simple but useful check is to compare the latest reports with historical trends. A sharp drop in the number of critical vulnerabilities on a stable scope, without a corresponding operational change, should trigger a manual verification.

Detection

In the absence of detailed indicators of compromise published in the brief source provided here, detection must rely on behavioral monitoring and on the logs available on the system, proxy, and application sides. The goal is to identify both an exploitation attempt and any subsequent alterations.

Indicators of compromise to look for

• Abnormal access to the console from unusual IP addresses, especially outside authorized administration ranges;
• spikes in HTTP errors or abnormal application responses on the Nessus interface;
• repeated requests to the same entry points with parameter variations;
• configuration changes not tracked by a change request;
• mass exports or unusual viewing of scan results;
• modification of policies, targets, schedules, or accounts;
• service restarts unexplained or repeated application errors;
• volume discrepancies in scan results without a known operational cause.

Useful logs and evidence sources

Depending on the deployed architecture, the following elements can be correlated:

• nessusd service logs;
• system logs via journalctl;
• logs from any reverse proxy;
• firewall logs;
• authentication traces;
• change history in the administration interface;
• recent report exports for comparison.

Examples of useful commands for an initial local review:

# System logs related to the service
sudo journalctl -u nessusd --since "2026-06-26"

# Service status and latest events
sudo systemctl status nessusd

On a reverse proxy such as Nginx or Apache, look for:

• sequences of numerous requests on the same endpoint;
• rising 500 or 400 codes;
• abnormal response sizes;
• access from unexpected countries, ASNs, or address ranges;
• times incompatible with usual administration practices.

Examples of weak network signals

Without claiming to provide universal exploitation signatures, some signals should draw attention:

• repeated attempts on the administration console port;
• access from known Internet scanners;
• administration sessions from unlisted IPs;
• a sudden increase in outbound traffic from the Nessus host to unusual destinations.

If the instance was publicly exposed, even briefly, a log review for the period preceding the patch is recommended. For organizations subject to traceability requirements, this review must be documented and, if necessary, integrated into an incident analysis.

Ecosystem perspective and remediation priorities

This alert is a reminder of a structural point: security tools are critical assets, not exceptions to the hardening cycle. Scan consoles, EDR, SIEM, backup tools, orchestrators, and bastions share the same problem: they concentrate privilege, visibility, and sensitive data. As such, they must be managed with a level of rigor at least equivalent to that applied to the most sensitive exposed applications.

In the real ecosystem, fragile practices are still often observed:

• console published on the Internet for convenience reasons;
• administration access open to an overly broad subnet;
• less frequent patching on “internal” tools;
• absence of specific monitoring of the security tools themselves;
• excessive trust in the native integrity of the produced results.

The Nessus case illustrates why these habits must evolve. A vulnerability scanner is not only a technical component; it is a decision source. If that source is compromised, the consequences go beyond the local incident and can contaminate the entire security governance chain.

For administrators and DevOps teams, the order of priorities is generally as follows:

• identify all Nessus instances;
• check the versions;
• reduce network exposure immediately;
• apply the fixed version published by Tenable;
• check the integrity of configurations and recent results;
• keep remediation evidence.

For CISOs, in parallel it is necessary to:

• assess whether the instance was exposed to the Internet or to an overly broad administration perimeter;
• determine whether a compromise review is necessary;
• re-examine the exposure policy for security tooling consoles;
• integrate these tools into crisis management and continuity exercises.

The source to follow remains the CERT-FR advisory of June 26, 2026 and above all the official Tenable advisory it references, for the CVE identifiers, any CVSS scores, the precise list of affected versions, and the fixed version to deploy. If your organization relies on national or sectoral security relays, also monitor any updates and possible enrichments to the advisory.

In practice, a Nessus console should never be considered just another server. If it is accessible, it must be segmented, logged, updated quickly, and monitored for integrity. This is particularly true in hybrid environments, at hosting providers, and in infrastructures where several teams access the same administration networks. To strengthen this type of asset over the long term, a review of hardening and secure operations measures remains recommended, notably via the best practices gathered at /categorie/pratiques.