On October 21, 2026, the PHP project released new versions of PHP to address a couple of critical vulnerabilities discovered in the software. They strongly encouraged everyone using PHP — about 70% of the sites on the internet — to update immediately, or face the prospect of attackers seizing control of unprotected servers.
Since the announcement, we’ve had a few security-conscious customers reach out to see if our software is affected. The short answer is no, we’re not vulnerable, but let’s dig into the details below.
Is your software impacted by PHP2Shell?
No. The pair of vulnerabilities, called PHP2Shell, only affect PHP. And since none of our products embed or borrow components from PHP, they’re all in the clear.
What about AlwaysUp Web Service? Does it use PHP?
Even though AlwaysUp Web Service serves web pages and is accessible from your browser, it’s not impacted by the bugs. That’s because it uses its own, internally developed networking code — not PHP.
Does your website use PHP? If yes, has it been patched?
Like the majority of the world’s websites, ours rely on PHP too. Our servers were vulnerable to PHP2Shell.
So we moved quickly to fix them. The team paused and patched all our machines on the evening of October 21, and only approved versions of PHP are running today:
How does your company respond to critical security issues like this?
As part of our information security program, we make it a point to apply operating system patches on a regular basis.
In general:
Patches to fix critical vulnerabilities are applied as soon as possible — automatically if possible and usually within 30 days.
And for truly exceptional threats like PHP2Shell, our goal is to take action within 24 hours of a fix becoming available.
On Linux, high, medium and low vulnerabilities are addressed as part of quarterly updates.
We update Windows machines at least monthly (after Patch Tuesday).
AlwaysUp manages the full lifecycle of every application it runs as a Windows Service. It starts each app at boot, monitors it 24/7 to keep it running, and closes it when the machine shuts down. That’s exactly the right level of babysitting necessary to ensure 100% uptime for your important programs.
But sometimes AlwaysUp can get in the way. That may happen during maintenance, when the application needs to be patched. For instance, things can get awfully messy if AlwaysUp tries to relaunch an application while its internal components are being updated!
The recommended solution? Stop your application in AlwaysUp whenever you need to take control. Once you start a fresh copy on your desktop, you’ll be free to do whatever you like.
But what if you don’t want to close the application? That is, you prefer to work with the already running process — just outside the control of AlwaysUp?
That’s where the detach feature comes in. It’s how to tell AlwaysUp to stop itself, but leave the application running.
How do I detach an application in AlwaysUp?
It’s super easy to detach an application from AlwaysUp. It’s really a single step but let’s take you through the process in great detail with a Python application running as a service on our test server.
We start with AlwaysUp already running Python. Process Explorer shows us the parent-child relationship:
To detach AlwaysUp from Python, we select Application > Detach from the menu:
Next, AlwaysUp asks to confirm. It mentions the PID (in this case, 4228) to clearly identify the process AlwaysUp is managing:
After confirmation, AlwaysUp exits but leaves Python running. As you can see here, PID 4228 is still active but “orphaned” in Process Explorer:
We’re now free to do whatever we like with PID 4228.
Can I detach from the AlwaysUp command line?
Yes. You can detach an application by running:
AlwaysUp.exe -detach <application-name>
where <application-name> is the name of your application in AlwaysUp.
What are your best tips for using detach?
Tip #1: Make sure working in Session 0 is OK
Your application continues to operate normally after AlwaysUp detaches. However, it will likely be running in Session 0 — the invisible desktop where Windows Services live. As a result, your program won’t be visible on your desktop and you won’t be able to interact with it.
The lack of visibility can be problematic. For instance, how do you launch your maintenance tasks without being able to control the application’s user interface?
The reality is that for situations where you need to interact with the application, it’s better to forgo detach and restart the application normally on your desktop.
Tip #2: Have a plan to return control to AlwaysUp
Remember to restart your application in AlwaysUp once the maintenance is complete!
You don’t want to leave your system vulnerable to reboots, crashes, and other costly interruptions.
I see that you have a new version of your software available or download. Can I upgrade for free? If not, how much does it cost?
— Irene
Hi Irene, thanks for reaching out.
Not all upgrades are free. And the answers to your questions depend on your specific situation. Let’s dig into the details.
Every license includes a free upgrade to the next version
When you buy our software, your license is valid for any release with the same major version number or the next. That is, your purchase includes a free upgrade to the next version.
For example, let’s say you bought AlwaysUp version 16. In that case, you can use:
Any version 16, and
Any version 17, because of the free upgrade to the next major version.
However, your license will not work with version 18 and later. You’ll need to purchase a discounted upgrade for that.
How to find the version number purchased
Your order page shows the version number you bought:
How to find the latest version number available
Visit our website to find the latest and greatest.
To find the version in use, open the software and choose Help > About from the menu. The window that comes up shows the information.
Here’s what that looks like in Service Protector:
The bottom line
Once you know the version you bought and the version you want to use, you can apply the upgrade policy to figure out if the upgrade is free or not.
Save 30% when you choose to buy an upgrade
If you’re ready to upgrade, be sure to take advantage of generous discount pricing.
An upgrade license for AlwaysUp costs $34.99 and an upgrade for Service Protector costs $69.99. Both are 30% off regular prices.
And just like a full license, an upgrade is good for the next version too. For example, if you pay to upgrade to AlwaysUp version 17 today, your upgrade to the future version 18 will be complimentary.
Frequently asked questions about upgrades
Since you inquired about upgrades, let’s review what other customers have asked our support team. Hopefully this information will help you decide if an upgrade is right for you or not.
What happens if I don’t upgrade? Will the software stop working?
The short answer is that nothing will happen. The software you bought will continue to function normally.
That’s because your license is perpetual. It has no expiration date and you can use it for as long as you like.
To be crystal clear, upgrading isn’t mandatory. That decision is entirely up to you.
Why should I upgrade?
We’re constantly improving our software. Every few months we add time-saving features, fix bugs, apply security patches and react to the unending sequence of updates from Microsoft. Indeed, you can see the steady progress in the release notes (AlwaysUp, Service Protector) and blog articles announcing new releases.
If you rely on our products in a commercial environment — where stability, compatibility, and security are paramount — we strongly recommend keeping your software up to date. It’s the best way to avoid problems and minimize surprises as Windows evolves.
We think it’s the fairest way to operate. Here’s our reasoning.
First, realize that our software is a one-time purchase. There are no ongoing subscription fees and the version you buy is yours to keep.
Second, our team keeps improving the software even after you’ve bought it. Each subsequent release brings new features and adds to the value you receive from the software.
But how should our small company fund that continuous development?
We could:
include the cost of lifetime upgrades in every license, or
switch to a subscription model, where customers pay a fee each month, or
charge only the customers who want to upgrade
We ruled out mandatory lifetime upgrades because that raises the cost for everyone — including those who never intend to update. And a subscription model is a poor fit for our modestly-priced utilities. That leaves charging for upgrades as the only viable solution.
But it’s a excellent one! Charging for upgrades is the most natural way for happy customers to reward us when we deliver added value. Furthermore, the funds from upgrades incentivize us to continue supporting the software and keep making it even better for everyone. It’s a win-win.
When buying an upgrade, will I need to enter any information from my previous orders?
No, you won’t have to enter anything from your previous purchase.
Just pay for the upgrade and our systems will verify eligibility on the back-end.
How often are major releases?
We aim to produce a major software update every 12-18 months. That’s enough time for us to build and deliver significant additional value to customers.
The upshot is that if you buy a license today, you’ll have at least a year (and up to 3 years) of free upgrades included in your purchase.
AlwaysUp version 17.5 — which installs any program as a robust Windows Service — is available for download. Here are the main highlights of this end-of-summer release.
Automatically restart your app if a supporting Windows Service isn’t running
Does your AlwaysUp application depend on a Windows Service? And when that service stops, will your application fail?
If that describes your situation, you should deploy the new “supporting service” sanity check. After you set it up, AlwaysUp will confirm that the service is running every few seconds.
Whenever AlwaysUp discovers that the service isn’t running, it will reset your application — and recycle the important service too, at your direction.
To deploy the new sanity check:
Choose Check that a Windows Service is running from the list of health checks:
On the next screen, choose the Windows Service AlwaysUp should monitor:
Catch HTTP error messages with the Web Server sanity check
Web servers can fail in unexpected ways.
And sometimes instead of crashing outright, they limp along returning valid responses (HTTP code 2XX) while spewing errors on the pages served.
Our team has retrofitted the web server sanity check to catch those faulty responses. Instead of relying on the HTTP code alone, AlwaysUp can now scan for a specific error message returned on the page. Just enter that text when configuring the sanity check:
With that new capability in place, AlwaysUp will thoroughly scan the body of each web server response and promptly restart your application if the error text is found.
Sanity checks inspect your application’s entire process tree
In the real world, Windows applications often deploy multiple processes to do their work. Many times there’s a parent process (the one that was started) and one or more child processes launched to perform specific tasks.
That arrangement posed a problem for some of AlwaysUp’s most popular sanity checks. They would only check the parent process and not the child processes, and sometimes that led to false positives.
Our solution is to extend those health checks to interrogate the entire process tree — the top-level process and all its sub-processes. That’s a new option is available to you when configuring some sanity checks.
For instance, let’s look at the network connections sanity check. A new setting is available on the main configuration window. Once you activate it, AlwaysUp will search the entire process tree for connections:
A similar option is available in the sanity check that restarts your application whenever it uses too many operating system handles. It’s new as well.
Control AlwaysUp from a command prompt
With Version 17.5, you can do much more with “AlwaysUp.exe” from an elevated command prompt.
Previous releases supported basic operations (start, stop, etc.) but XML import, XML export, detach, and help are new. Let’s explore those additions.
It’s possible to stop AlwaysUp but leave your application running. That detach feature — which is available from the “Application” menu — can be useful when you need to perform application maintenance and don’t want AlwaysUp to get in the way.
To detach an application, run:
AlwaysUp.exe -detach <application-name>
Help/usage
To see the full command line capabilities, run:
AlwaysUp.exe -help
A window with the details will pop up:
Even though these enhancements don’t rival the power and flexibility of AlwaysUp Command Line Tools (CLT), we expect customers will put them to good use!
Most notably, instead of writing general “updated” records whenever someone edits an application, AlwaysUp mentions what was changed. To show you what we mean, here’s what the record looks like when user Mike Jones updates an application’s executable path:
We’re confident these security-centric additions will help busy administrators as they try to figure out who did what.
Other improvements and fixes
On the Monitor tab, AlwaysUp now shows the details of the sanity check when you hover over (or click) the green check mark:
For completeness, AlwaysUp writes Event Log records whenever services are controlled from the command line. You’ll see entries like “Start requested (command line)” or “Stop requested (command line)” whenever those operations are invoked.
As you can see from the full report, none of VirusTotal’s 91 virus detection engines found any issues at all:
Upgrading to AlwaysUp 17.5
If you bought AlwaysUp version 16 (on or after February 7 2025), you can upgrade to version 17.5 for free. Simply download and install “over the top” to preserve your existing applications and all settings. Your registration code will continue to work as well.
A green “Running” status in Services.msc can be very reassuring. Indeed, it means that your service’s executable is still active.
But it’s NOT proof that your application is healthy — serving requests, processing jobs or accepting connections.
The truth is that even though a Windows Service is technically running, it can still be utterly useless. A lifeless zombie, dead on its feet.
The most frustrating kind of outage
Application crashes are never welcome.
But in the spectrum of failures, a clear, unambiguous crash (where the process dies) is the easiest to deal with. That’s because it’s relatively straightforward to determine when a process exits and react accordingly.
It’s far more difficult to catch failures when the service is still running but not doing its work. Conventional monitoring tools tell us that everything is fine, yet the service is actually down because customers cannot complete the tasks they need to perform.
The result? Prolonged, frustrating outages.
Common examples of “running but not working”
If we define failure as “not working”, there are a variety of ways a running Windows Service can fail.
For example, users will complain loudly when:
A network service accepts a connection but never returns a response.
A queue processor is alive but no longer consuming messages.
A database service is running but cannot accept useful work.
A web server accepts HTTPS requests but always responds with a 5XX error.
An integration service has lost access to a remote dependency.
A backup service stops uploading files to the cloud.
You can probably think of other scenarios as well.
Why Windows cannot always see the problem
Windows can easily determine whether your service has started, stopped or reported a status. It can even detect when your service process crashes — and quickly restart it.
Keep in mind that the Windows Services system is built to manage a wide range of applications. The recovery functionality is very generic because it must support anything a programmer can dream up.
And because of that general-purpose approach, Windows doesn’t even attempt to understand how your program works. The result is that Windows never checks if your service is actually doing its job.
Service Protector checks the work, not just the process
Instead of just checking if the process is alive or not, Service Protector digs in and confirms that your application is actually doing its job.
For example, Service Protector can check:
Is your service using too much memory or CPU?
Is a drive letter mapped and accessible?
Was a special file updated recently?
Is a network server accepting TCP/IP connections?
Is a web server responding properly?
Is an important/helper program or service running?
Does your service have one or more network connections open?
Was an adverse Windows event reported while your service was running?
Does your service have too many operating system handles open?
And if none of those work for you, extend Service Protector with a custom health check — a probe that works for your unique situation.
Example #1: Automatically restart your service if it’s using too much memory
If your service is a memory hog, have no fear. Service Protector will calculate the executable’s memory usage every few seconds and promptly restart it if it exceeds a specific threshold.
Just enter the threshold and you’ll be good to go:
Example #2: Automatically restart your service if it has no open network connections
Are you running a Windows Service that must always be listening for connections?
If so, Service Protector will periodically scan your server and recycle it if it’s not accepting connections.
Afterwards, enter how often Service Protector should check your server and you’ll be all set.
Try Service Protector completely free for a month — no strings attached
Download the free 30-day trial and put Service Protector to the test yourself, in your unique environment. Setup takes a couple of minutes, and you’ll know soon if it’s what you need.
100% compatible with all current versions of Windows
I see that you have a new version of your software available or download. Can I upgrade for free? If not, how much does it cost?
