Update Metasploit : How to Update Metasploit in Kali Linux Latest Version and Why msfupdate Fails [Guide]

To update Metasploit on Kali Linux, open a terminal and run sudo apt update followed by sudo apt install metasploit-framework. That is the entire procedure. The command almost every tutorial tells you to use — msfupdate — does not work on Kali at all, and it never will, because Metasploit is part of the operating system here rather than something you installed separately. If that command is what sent you looking for this page, nothing is broken on your machine.

Why Jake owns a Kali machine at all

Last year somebody called Jake's shop pretending to be his payment provider, walked him through a "verification" process on the phone, and left with $260 in gift-card codes and an afternoon of his life. He was embarrassed about it for about a week, which is roughly six days longer than he should have been, and then he did something better than being embarrassed: he signed up for an evening security course.

The course handed out a Kali virtual machine. Jake used it for a term, passed, put it away, and did not open it again for nearly two years. Last week he wanted to look at something in Metasploit again, booted the VM, and found a tool that had aged like milk.

So he did what the top result told him and typed msfupdate.

"It says the command doesn't exist," he reported. "So either I broke it, or I never had it."

"Neither," Ethan said. "You're being told something true in the least helpful way possible. That command exists for people who installed Metasploit by hand, on a system that knows nothing about it. Yours came with the operating system. Kali's package manager owns it, and it does not appreciate being second-guessed by a tool that thinks it is in charge."

"Then why does every single guide say to run it?"

"Because they were written when it worked, and nobody goes back."

That is the honest shape of this whole topic. The procedure is one line long. Everything that follows is the list of things that go wrong around it — arranged by symptom, so you can go straight to yours.

The one command, and why there is no second one

On Kali, Metasploit is a package like any other. apt update asks the repositories what versions exist right now; apt install on an already-installed package upgrades it to that version. There is no separate updater, no repository to add and nothing to register.

What most people should actually run, though, is this:

Updating Metasploit alone is a perfectly valid thing to do when you have a reason — a specific module you need today, a slow connection, a machine you would rather not disturb. As a habit it is a slow way to create problems, because packages are built expecting their neighbors to move along with them. If you are unsure which position you are in, checking which Kali version you are on takes one command and tells you how far behind you have drifted.

Symptom: msfupdate says command not found, or refuses to run

This is the single most common reason people go looking for this page, so let us be unambiguous: nothing is wrong with your installation.

msfupdate is not supported when Metasploit is installed as part of the operating system. On Kali it always is. Depending on how old your system is you will get one of two responses — either the command genuinely is not there, or it is there and tells you to use your package manager instead. Both mean the same thing, and the answer to both is the apt command above.

Symptom: apt fails before it ever reaches Metasploit

If the update dies during apt update, Metasploit is not your problem yet. Two failures account for nearly all of these, and both are about the machine rather than the tool.

The signing key, on anything installed before April 2025

This is exactly Jake's situation, and it catches every dormant Kali machine. Kali replaced its repository signing key in April 2025. An installation older than that carries a keyring that no longer matches what the repositories are signed with, so apt rejects everything — typically with a message naming sqv, the signature verification tool Kali now uses. It reads like corruption. It is a key rotation.

The full version, including what to do when that download is itself what fails, is in our dedicated write-up: fixing the missing Kali signing key and the sqv apt error. One thing not to do: the old apt-key adv advice. That command has been removed, and current Kali does not read the keyring it used to manage, so following it appears to succeed while changing nothing.

dpkg was interrupted

Metasploit is a large package, which makes it a popular place to lose a connection, close a laptop lid or run out of patience. If an earlier attempt stopped part way, apt refuses to begin anything new until that job is finished:

Then start over. If that first command fails too, the problem is one specific package rather than dpkg itself, and the dpkg was interrupted guide walks through finding which one.

Symptom: it said it updated, but the version did not change

This one produces real confusion, because apt reports success and msfconsole then contradicts it. Two questions settle it in about fifteen seconds.

apt policy prints an installed version and a candidate version. If they match, the package is current and apt did its job correctly.

Then look at which msfconsole. If it answers /usr/bin/msfconsole, that is the packaged copy and everything is consistent. If it answers something under /opt, you have found the bug: there are two Metasploits on this machine, and your shell is finding the other one first. The apt package updated perfectly. You have simply not been running it.

How the second copy gets there

Somebody follows a general Metasploit guide — not a Kali one — and runs Rapid7's own installer. That installer is entirely legitimate and completely correct for a machine that does not already have Metasploit. On Kali it produces a duplicate, installed outside the package system, that the package system cannot see, update or remove.

Pick one and remove the other. Keep the Kali package unless you have a specific reason not to, since that is the copy that updates itself along with everything else. Then confirm with which msfconsole that only one answer comes back.

Symptom: it starts, then complains about the database

After an update, msfconsole frequently opens with a complaint that it cannot connect to the database. Nearly always this means PostgreSQL is not running, not that anything is damaged.

Metasploit keeps a database — hosts you have looked at, services found, results of scans — in PostgreSQL, and that service does not always start on boot:

msfdb init creates the database and the user if they have never existed; on a system where they already do, it will simply tell you so. db_status inside the console is the check that matters, because it reports what Metasploit itself can see rather than what the service claims.

"Do I actually need it?" Jake asked, once it was working.

"Not to fire a single module, no. You need it the moment you care about what you did yesterday." Without the database, Metasploit has no memory — no stored hosts, no saved results, no workspaces keeping one piece of work separate from another. For an evening of learning that is fine. For a course, or anything you will come back to, it is two commands well spent.

Confirming you are actually current

This prints the version without loading the whole console, which is the fast way to check. The first full launch after an update is genuinely slow — Metasploit rebuilds its module cache when the package changes, and there are thousands of modules to index. That is a one-off cost per update and not a fault. If every start is slow, suspect a database that is configured but unreachable, so it sits waiting for a connection that never comes.

As for how often to do any of this: the project ships changes constantly and cuts releases roughly weekly, and Kali packages them shortly after. A weekly full-upgrade keeps you close enough to current for any normal purpose. Updating daily mostly downloads things, because in most weeks the modules you personally touch have not moved at all.

If your Kali has been asleep for a year or more

Jake's machine had not been booted since his course ended, and a two-year gap on a rolling distribution is a different job from a weekly update. In order:

1. Snapshot it first if it is a VM. Everything below is reversible if you do this, and awkward if you do not.
2. Fix the signing key, because on anything older than April 2025 nothing else will run.
3. Run sudo apt update && sudo apt -y full-upgrade and expect several gigabytes. Long silences on packages that rebuild the initramfs or regenerate caches are normal.
4. Reboot, since a kernel almost certainly changed.
5. Start PostgreSQL and run msfdb init, then check db_status.

There is an honest alternative worth naming: on a machine this stale, downloading a current image and starting fresh is sometimes less work than dragging two years of accumulated state forward, particularly if there is nothing on it you would miss. Upgrading is the right answer when the machine has your notes, your workspaces and your configuration on it. Reinstalling is the right answer when it is just a lab box that happens to be old.

Either way, once it boots, the rest of the site's Kali material assumes a current system: running tools through kernel-level Tor isolation with oniux, fixing the MAC address change error, or running an AI model offline on the same machine.

What an update replaces, and what it never touches

The question underneath most people's hesitation about updating is one they rarely ask out loud: will this delete my stuff? The answer is no, and it is worth understanding why, because the reason is structural rather than a promise.

There are two separate places involved:

So a module you wrote yourself and dropped in ~/.msf4/modules survives every update, as do your workspaces, because those live in the database rather than in any file the package owns. This is also why putting your own work anywhere under /usr/share is a bad idea — that directory is the package's, and the next update will quietly take it back.

Two small things worth knowing afterwards. Inside msfconsole, reload_all picks up module changes without restarting the console. And a machine that has been updating for a long time accumulates downloaded package files, which is a genuinely common reason an update fails on a small VM disk:

One reassurance on scope: msfvenom, msfdb and the rest all come from the same package. There is no separate step for any of them, and no version of this where one is current and another is not.

Kali under WSL, where one command is different

A lot of people now run Kali inside Windows through WSL rather than in a virtual machine, and it mostly behaves identically. The apt commands above are unchanged. One thing is not.

systemctl may not work. WSL does not run systemd unless you tell it to, and without systemd the command to start PostgreSQL simply fails — which lands you in the database error from earlier, chasing a problem that is not really about Metasploit. You have two options:

Option B is the better long-term answer, because plenty of other Kali tooling expects systemd to exist. Option A gets you working in five seconds.

The other WSL surprise is that the default Kali install is deliberately minimal — it ships a base system rather than the full tool set, so Metasploit may not be there at all. In that case you are installing rather than updating, and the same command does both.

Frequently asked questions

How do I update Metasploit in Kali Linux?

Open a terminal and run sudo apt update followed by sudo apt install metasploit-framework. That is the whole procedure on Kali. Because Kali is a rolling distribution, sudo apt update and sudo apt full-upgrade also brings Metasploit along with everything else, which is what most people should run instead. There is no separate updater to install and no repository to add.

Why does msfupdate not work on Kali Linux?

Because msfupdate is not supported when Metasploit is installed as part of the operating system, and on Kali it is. Metasploit arrives as a Kali package, so Kali's package manager owns it and updating it any other way would fight the package system. Depending on your version you will see either command not found or a message telling you plainly to use apt instead. Neither is a fault on your machine.

How do I check which version of Metasploit I have?

Run msfconsole --version from a terminal, which prints the version without loading the full console. To see what the package system thinks, run apt policy metasploit-framework, which shows the installed version and the candidate version available from the repository. If those two differ after an update, the update did not actually complete.

Why does Metasploit say it cannot connect to the database?

Almost always because PostgreSQL is not running. Metasploit stores hosts, services and results in a PostgreSQL database, and that service does not start automatically on every boot. Run sudo systemctl start postgresql, then sudo msfdb init to create the database if it has never been set up. Inside msfconsole, db_status tells you whether the connection is live.

Do I need the database to use Metasploit?

No. Metasploit runs perfectly well without it, and you can ignore the warning if you are only trying one module. What you lose is the memory: stored hosts and services, saved scan results, and the workspace feature that keeps separate engagements apart. For anything longer than a single afternoon the database is worth the two commands it takes to set up.

I updated but msfconsole still shows the old version. Why?

Usually because you are running a different copy than the one you updated. Run which msfconsole and check the path. If it points somewhere under /opt rather than /usr/bin, you have a second installation from Rapid7's own installer, and your shell is finding that one first. The apt package updated correctly. Your PATH is sending you to the other one.

Can I install Metasploit from Rapid7's installer on Kali?

You can, and you should not. Kali already ships and maintains the package, so adding the official installer leaves two copies on one machine competing for the same command name. That is where the mysterious version mismatches come from. If you already have both, decide which one you want, remove the other completely, and confirm with which msfconsole that only one remains.

Why does apt update fail before it even reaches Metasploit?

On an installation older than April 2025 it is the signing key. Kali changed its repository key then, so an older image carries a keyring that no longer matches and apt refuses everything, usually with a message mentioning sqv. Fetch the current keyring from archive.kali.org and replace the one on disk, then run apt update again. Nothing installs until that is fixed.

What does dpkg was interrupted mean during a Metasploit update?

It means an earlier package operation stopped part way and left work unfinished, so apt refuses to start anything new. Metasploit is a large package, so it is a common place to lose a connection or close a laptop mid-install. Run sudo dpkg --configure -a to complete the interrupted job, then sudo apt --fix-broken install, then try again.

How often is Metasploit updated?

The project itself ships changes constantly and cuts releases roughly weekly, and Kali packages those on its own schedule shortly after. In practice a weekly apt full-upgrade keeps you close enough to current for any normal purpose. Updating daily achieves very little beyond downloading, because most weeks the modules you personally use have not changed.

Should I use apt upgrade or apt full-upgrade on Kali?

full-upgrade, essentially always. Kali is a rolling release, and plain upgrade refuses any change that would remove a package. On a rolling distribution that restriction blocks a large share of legitimate updates, so plain upgrade silently leaves you half current. full-upgrade is the normal, expected command on Kali rather than an aggressive one.

How do I update just Metasploit without upgrading everything else?

Run sudo apt update then sudo apt install metasploit-framework, which upgrades that package and only what it directly depends on. It works, but on a rolling distribution holding everything else back is a slow way to create problems, because packages are built expecting their neighbors to move together. Use it when you have a reason, not as a habit.

Why is msfconsole so slow to start?

The first launch after an update is genuinely slow, because Metasploit rebuilds its module cache after the package changes and there are thousands of modules to index. That is normal and it is a one-off cost per update. If every launch is slow, the usual cause is a database that is configured but not reachable, so it waits on a connection that never arrives.

Will updating Metasploit delete my custom modules or saved workspaces?

No, and the reason is structural rather than a promise. The package owns /usr/share/metasploit-framework and replaces it on every update. Your own work lives in ~/.msf4, which no package manager writes to, and your workspaces live in the database. Custom modules placed in ~/.msf4/modules therefore survive indefinitely. Anything you put under /usr/share does not, because the next update takes that directory back.

How do I update Metasploit on Kali running under WSL?

With the same apt commands, because WSL runs a normal Kali underneath. The one difference is that WSL does not run systemd unless you enable it, so systemctl start postgresql fails and the database error follows. Either use sudo service postgresql start, which works without systemd, or add a boot section with systemd=true to /etc/wsl.conf and restart WSL with wsl --shutdown.

Is it safe to run Metasploit updates on a system I use for other things?

The update itself is a normal package operation and carries no special risk. The better argument for keeping Kali in a virtual machine is everything else: a security distribution is a working environment you will deliberately break, snapshot and roll back. Keep it separate from the computer that holds your accounts and your work, and take a snapshot before large upgrades.

Two years of updates, one line long

Jake's machine took about forty minutes in the end, most of it spent downloading. The command that did the work was one line. The command that wasted his evening was the one every guide told him to run first.

"So the actual skill," he said, "is knowing which instructions are stale."

"That's most of it, on Linux. The commands are easy. Working out which decade a page was written in is the hard part."

Which, for what it is worth, is the reason this post exists in the shape it does. The answer at the top is three words long. Everything after it is here because something in the middle went wrong for somebody, and nobody had written down why.

Revision note. Originally published 9 April 2022 and rewritten on 8 August 2026. The core instruction has not changed and was right the first time — on Kali you update Metasploit with apt. What has changed is everything around it. Kali replaced its repository signing key in April 2025, which now stops apt on any older installation before Metasploit is ever reached, so that is dealt with first here. Also new: the two-installation case that makes a successful update look like a failed one, the PostgreSQL steps behind the database warning, and a plain statement that msfupdate is unsupported on Kali, which the original only mentioned in passing. If you are coming back to a machine that has been sitting untouched for a year or two, none of this is a sign you did anything wrong — it is just what a rolling distribution looks like after a long nap, and it all recovers. If a step here does not match what your terminal says, do let us know, we will correct it as usual.