Nessus Plugins Out of Sync in Tenable.sc: Causes and Manual Update

If you run Tenable Security Center (Tenable.sc), you have almost certainly seen a scanner under Resources → Nessus Scanners showing “Plugins Out of Sync”. Most of the time it is temporary: SC pushes the new plugin set, the scanner compiles it, and a few minutes later the status goes back to “Working”. Sometimes, though, a scanner stays out of sync for days, and your scans keep running with outdated plugins.

This guide covers the common causes of Nessus plugins getting out of sync, how to figure out which one applies to you, and how to update the plugins manually when the automatic push simply won’t finish.

How plugin updates work for SC-managed scanners

A Nessus scanner managed by Tenable.sc does not download plugins from the internet. It gets them from SC:

1. SC downloads the plugin set from Tenable.
2. Roughly every 15 minutes, SC checks the plugin set on each scanner it manages.
3. If the scanner’s set matches SC’s, nothing is sent. If it doesn’t, SC pushes its set to the scanner, and the scanner compiles the plugins.

Two things follow from this:

• “Plugins Out of Sync” simply means the scanner’s plugin set does not match SC’s. The push may be in progress, may have failed, or may never have started.
• You cannot point an SC-managed scanner at the internet feed instead. As long as it is managed by SC, SC is its only plugin source.

Common causes

Step-by-step troubleshooting

1. How many scanners are affected?

If only one scanner is out of sync, the problem is most likely on that scanner: AV, disk or licensing. If several are affected, look for what they have in common. Are they all at the same site or behind the same WAN/VPN path? Are they all on the same Nessus version? Is SC’s own plugin update succeeding?

2. Is the scanner healthy?

From the SC server:

curl -k https://<scanner_ip>:8834/server/status

If it returns "status":"ready", the network path and the Nessus service are fine. "pluginSet":false means there are no plugins on the scanner at all.

On the scanner itself, check licensing and registration:

# Windows (elevated PowerShell)
cd "C:\Program Files\Tenable\Nessus"
.\nessuscli.exe fetch --check

# Linux
/opt/nessus/sbin/nessuscli fetch --check

3. Is there a push loop in the SC log?

sudo grep -iE "plugin|<scanner_name>" /opt/sc/admin/logs/$(date +%Y%m).log | tail -40

If you see Updating plugins on Scanner '...' repeating for the same scanner about every 15 minutes, with nothing indicating completion, the pushes are starting but never finishing.

4. Is traffic flowing, and for how long?

Watch the push connections on the SC server:

watch -n 10 "sudo ss -tnpi '( dport = :8834 )' | grep -oE '[0-9.]+:8834|busy:[0-9]+ms|bytes_sent:[0-9]+'"

• bytes_sent: how much data this connection has sent.
• busy: how long the connection has been sending (in ms).

If connections are consistently closed after a fixed time (for example around 900,000 ms) and reopened from zero, and bytes_sent never reaches the package size, your problem is timeout versus bandwidth.

To see the size of the package being pushed, look at the open files of the PHP process doing the push:

for p in $(sudo ss -tnp '( dport = :8834 )' | grep -oP 'pid=\K[0-9]+' | sort -u); do
  ip=$(sudo ss -tnp '( dport = :8834 )' | grep "pid=$p," | awk '{print $5}')
  sudo ls -lL /proc/$p/fd 2>/dev/null | awk -v ip="$ip" '$5 > 100000000 {print ip, $5}'
done

The package size depends on the Nessus version family and can range from several hundred MB to more than 1 GB. You can estimate the throughput needed to push it within 15 minutes:

required_Mbps = package_size_MB × 8 / 900

For example, an 800 MB package needs a sustained ~7 Mbps on a single TCP connection. Over a high-latency VPN tunnel, a single connection can be much slower than the link’s total capacity.

5. Are there errors on the scanner?

# Windows
Select-String -Path "C:\ProgramData\Tenable\Nessus\nessus\logs\nessusd.messages" -Pattern "error|fail|denied|compil" | Select-Object -Last 30
Get-Content "C:\ProgramData\Tenable\Nessus\nessus\logs\backend.log" -Tail 50

# Linux
grep -iE "error|fail|denied|compil" /opt/nessus/var/nessus/logs/nessusd.messages | tail -30
tail -50 /opt/nessus/var/nessus/logs/backend.log

“Access denied” or file-not-found errors usually point to AV/EDR interference. Make sure the folders and processes on Tenable’s File and Process Allowlist page are excluded.

Fixes

AV/EDR, disk space or network devices

Remove the cause first: add the exclusions, free up disk space, or ask for an IPS/proxy exemption for 8834/TCP. Then select the scanner in SC and click Update Status. SC will retry the push on its next check.

“Could not validate this preference file”

This error means Nessus cannot validate its registration against the machine’s identity. It usually shows up after a VM was cloned, moved to another host, reverted to a snapshot, or had its hostname or MAC address changed. First make sure your PowerShell or terminal is running as administrator/root, since running without elevation can produce the same error. Then:

net stop "Tenable Nessus"
.\nessuscli.exe backup --create nessus_backup
.\nessuscli.exe fix --reset
.\nessuscli.exe fetch --security-center
net start "Tenable Nessus"

Two warnings:

• Don’t use fix --reset-all. It also deletes users, including the account SC uses to connect.
• fetch --security-center switches Nessus into SC-managed mode, which hides the policy and scan pages in the local web UI. If you keep policies in the scanner’s own UI, export them via Policies → Export before running this command.

Slow link: increasing the timeout

The push duration is capped by the ScannerStatusTimeout setting in SC. To see the current value:

sudo /opt/sc/support/bin/sqlite3 -header -table /opt/sc/application.db \
  "select name,value from Configuration where name='ScannerStatusTimeout'"

If the value is low (for example 120 or 300), you can raise it as Tenable describes:

sudo /opt/sc/support/bin/sqlite3 /opt/sc/application.db \
  "UPDATE Configuration SET value='900' WHERE name='ScannerStatusTimeout'"

Tenable explicitly recommends not exceeding 900 seconds, because higher values can cause an update loop and make SC unstable. In practice, here’s why: SC can start a new push to the same scanner on its 15-minute check without waiting for the previous one to finish. If the timeout is longer than 15 minutes, you end up with several parallel connections carrying the same package, which puts even more load on an already narrow link.

If the value is already 900 and the push still doesn’t fit, go for a manual update instead of raising it further. If you did raise it temporarily, set it back to 900 as soon as your scanners show “Working”.

Manual (offline) plugin update

This procedure is based on Tenable’s “Plugins Out of Sync” knowledge base article. Instead of relying on SC’s push, you deliver the plugins to the scanner through a path that has no timeout. The scanner stays managed by SC; this only resolves a stuck initial push.

1. Download the plugin archive (on the SC server)

Build the download URL from SC’s own subscription credentials:

L=$(sudo /opt/sc/support/bin/sqlite3 /opt/sc/application.db \
  'SELECT value FROM Configuration WHERE name = "PluginSubscriptionLogin"')
P=$(sudo /opt/sc/support/bin/sqlite3 /opt/sc/application.db \
  'SELECT value FROM Configuration WHERE name = "PluginSubscriptionPassword"')
curl -o /tmp/all-2.0.tar.gz "https://downloads.nessus.org/get.php?f=all-2.0.tar.gz&u=$L&p=$P"

If you don’t have shell access, you can find the same values in sc-configuration.txt inside a diagnostics file generated from System → Diagnostics in the SC UI.

Note: This URL contains your subscription credentials. Don’t paste it into tickets, forums or documentation.

It’s a good idea to update SC’s own plugins right before downloading. If the archive you download is newer than SC’s set, the scanner may keep showing “out of sync” for a while.

2. Stop the Nessus service on the scanner

# Windows
net stop "Tenable Nessus"

# Linux
systemctl stop nessusd

While the service is stopped, SC can’t push. Any running push connections are dropped, and the file copy gets the full link.

3. Copy the archive to the scanner

On slow or unreliable links, use a method that can resume:

# Windows
robocopy \\<source>\<share> C:\temp all-2.0.tar.gz /Z /R:5 /W:10

# Linux
rsync --partial --progress all-2.0.tar.gz <scanner>:/tmp/

When the copy finishes, compare the file size with the source.

4. Install the plugins

# Windows
cd "C:\Program Files\Tenable\Nessus"
.\nessuscli.exe update C:\temp\all-2.0.tar.gz

# Linux
/opt/nessus/sbin/nessuscli update /tmp/all-2.0.tar.gz

5. Edit plugin_feed_info.inc

To avoid a feed error when logging in to Nessus after a manual update, the file must contain a PLUGIN_FEED_TRANSPORT line. It should look like this (the PLUGIN_SET value comes from the archive):

PLUGIN_SET = "YYYYMMDDHHMM";
PLUGIN_FEED = "ProfessionalFeed (Direct)";
PLUGIN_FEED_TRANSPORT = "Tenable Network Security Lightning";

On Windows, the file is at C:\ProgramData\Tenable\Nessus\nessus\plugins\plugin_feed_info.inc. The safest approach is to note the current PLUGIN_SET value and rewrite the file cleanly:

$inc = "C:\ProgramData\Tenable\Nessus\nessus\plugins\plugin_feed_info.inc"
Get-Content $inc

Set-Content -Path $inc -Encoding ASCII -Value @(
  'PLUGIN_SET = "YYYYMMDDHHMM";'
  'PLUGIN_FEED = "ProfessionalFeed (Direct)";'
  'PLUGIN_FEED_TRANSPORT = "Tenable Network Security Lightning";'
)
Get-Content $inc

Watch out for two Windows pitfalls:

• Don’t use Add-Content. If the file has no trailing newline, the new line gets glued to the end of the previous one.
• In Windows PowerShell, -Encoding UTF8 adds a BOM to the start of the file. Use ASCII.

On Linux, the file is at /opt/nessus/lib/nessus/plugins/plugin_feed_info.inc and can be edited with any text editor.

6. Compile first, then start the service

# Windows
.\nessusd.exe -R
net start "Tenable Nessus"

# Linux
/opt/nessus/sbin/nessusd -R
systemctl start nessusd

The order matters. If you start the service before compiling, the web UI may show no plugins even after compilation completes successfully, and you’ll need to restart the service. Compilation can take 15–40 minutes depending on the hardware. Don’t close the window until it finishes.

7. Verify

curl -k https://<scanner_ip>:8834/server/status

You should see "pluginSet":true, "pluginData":true and "status":"ready". Loading the plugins into memory can take a few minutes after the service starts. Then select the scanner in SC and click Update Status. Tenable suggests allowing up to 30 minutes for the status to change to “Working”.

Making it stick

A manual update brings the scanner up to date. But if the root cause is a slow link, the same thing can happen again with the next large plugin update. So:

• Watch the first scheduled push. After the manual update, check bytes_sent in the ss output during the next automatic update. If it stays small and finishes within the timeout, you’re done. If hundreds of MB are going out again, you need a permanent fix.
• Ask your network team for the right thing. The bottleneck is often not the link’s total capacity, but the speed of a single TCP connection over a high-latency tunnel. Ask for “X Mbps per connection for 8834/TCP”, not just “more bandwidth”. Calculate X with the formula above. QoS, shaping and MSS/MTU settings are also worth reviewing.
• Be careful with Nessus upgrades. SC sends a separate package for each Nessus version family. After upgrading a scanner at a slow site, keep an eye on the first push.
• Talk to Tenable Support. If you have several remote sites, ask Tenable about the recommended architecture for scanners on slow links.