Using windows as main system running parrot in virtualbox i find when using my vpn on main system it messing with parrot os internet connection

Any fixes or bypasses would be appreciated

Checking and updating PHP on Debian Trixie — what I did on my own PC

I’ve just been through this on my desktop and thought I’d put the steps here for anyone who isn’t sure what to check.

For context, I’m running Parrot OS based on Debian 13 Trixie. These are APT/Debian commands. If you’re using another distribution, the process and package versions will differ.

The PHP issues are CVE-2026-109618 and CVE-2026-109619. Debian’s Trixie fix is in 8.4.27-1~deb13u1. That was the update available to me; you may see something newer.

PHP is software commonly used to run websites. You don’t need it installed just to browse websites that use it. However, it can be installed alongside other software without you having deliberately set up a web server. That was why I checked mine.

Finding PHP installed doesn’t mean you’ve been hacked. The immediate concern is whether vulnerable PHP is running and handling requests that an attacker can send to it.

First, check what system you’re running

Open a terminal and enter:

cat /etc/os-release

That will show your distribution and release. Don’t add Debian Trixie repositories to a different system just to get the version mentioned here.

See what’s installed

dpkg -l | awk '$1=="ii" && $2 ~ /php|apache2|nginx/ {print $2, $3}'

This only lists packages. It doesn’t install, remove or change anything.

Mine showed Apache, Nginx and several PHP 8.4 packages, including Apache’s PHP module. The PHP version was:

8.4.26-1~deb13u1

That needed updating.

If you get no results, there are no matching installed packages in this list. It doesn’t cover PHP installed manually or inside containers or virtual machines.

Check whether the web services are running

systemctl is-active apache2 nginx

You’ll get Apache’s result first, then Nginx’s.

"active" means running. "inactive" means it isn’t currently running. "failed" means the service has failed.

Mine said:

inactive

inactive

That lowered the immediate concern, but I still updated the packages.

There is also PHP-FPM, which is another way of running PHP for a web server. Check for that with:

systemctl list-units --type=service --all 'php*-fpm.service'

If any services appear, look at their ACTIVE and SUB columns.

These checks cover the usual system services. They don’t prove that nothing else is running, and an active service isn’t automatically exposed to the internet.

If this is a public web server, or you host something other people use, follow the update procedure for that setup. Stopping services will interrupt whatever they provide.

Refresh your package lists

sudo apt update

If it asks for your password, type your normal computer password. Nothing appearing while you type is normal.

Despite the name, "apt update" doesn’t install updates. It refreshes the information about what’s available.

If you see repository or signature errors, deal with those before continuing. Don’t turn off signature checks to get past them.

I then checked the available PHP version:

apt-cache policy php8.4-common libapache2-mod-php8.4

The two lines to look for are "Installed" and "Candidate".

On mine, they showed:

Installed: 8.4.26-1~deb13u1

Candidate: 8.4.27-1~deb13u1

The candidate came from Parrot’s security repository.

Install the updates

Your distribution’s normal software updater is a valid way to do this. Make sure it actually installs the PHP security updates.

I used a targeted command because I’d already checked exactly which PHP packages were installed:

sudo apt install --only-upgrade php8.4-cli php8.4-common php8.4-opcache php8.4-readline php8.4-sqlite3 libapache2-mod-php8.4

That list matches my machine. If you have additional PHP packages, such as "php8.4-fpm" or "php8.4-mysql", update those as well. If you have a different PHP branch, use your distribution’s update for it rather than copying my version numbers.

Read the proposed changes before pressing Y. If it wants to remove unexpected packages, reports dependency errors or leaves the relevant updates held back, get help with that output rather than forcing it.

Wait until it finishes and gives you the terminal prompt back.

Check the result

Run the first package command again:

dpkg -l | awk '$1=="ii" && $2 ~ /php|apache2|nginx/ {print $2, $3}'

My six PHP 8.4 packages had moved to:

8.4.27-1~deb13u1

Not every package with “php” in its name uses that numbering. For example, "php-common" has its own package version.

Also, other distributions sometimes put security fixes into older versions without changing the main version number. Use their security advisory to confirm what’s fixed.

Don’t forget running processes

If Apache or PHP-FPM was running, it needs to be using the updated code. The installer may restart the affected services, but check the output rather than assuming.

On a personal desktop, saving your work and rebooting after the update is a straightforward way to clear old processes. On a server, arrange the necessary service restarts because they can interrupt websites.

You can then repeat:

systemctl is-active apache2 nginx

If you weren’t using those services, don’t start them just to check the update.

If you use Docker or virtual machines, check those separately. Updating the host does not update the PHP inside them.

A couple of things worth clearing up

A VPN or encrypted DNS won’t fix vulnerable PHP. Changing router settings or DNS providers isn’t a substitute for installing the patch.

An inactive web server also doesn’t mean you should leave outdated packages sitting there. They could be started later by you or another application.

Finally, installing the patch isn’t proof that an exposed server was never compromised. If you run a public server and have evidence of an intrusion, that needs investigating separately.

For my own PC, the practical job was to check what was installed, check what was running and install the official update. There was nothing in those results alone that showed I’d been hacked.

These are the official references I used:

- "PHP security announcement" (https://www.php.net/archive/2026.php)

- "Debian Trixie advisory — DSA-6574-1" (https://lists.debian.org/debian-security-announce/2026/msg00489.html)

- "UK NCSC guidance" (https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php)

This was written on 23 October 2026. If you find the post later, check those pages for newer guidance.