Patched Server Still at Risk?
A patch closes a security flaw. But it may not remove an attacker who already got in, replace a stolen password or token, or restart a service that is still running old code.
This week’s stories show what to check after an update.
Yours in Open Source,
Dave Wreski, Founder
A Patch May Not Remove an Attacker’s Backdoor
BeyondTrust fixed a flaw in its Remote Support software after attackers used it to break into a system. Investigators found that the attackers had left tools behind, including a hidden way to get back in. They had also deleted logs.
If your self-hosted system was exposed to the internet while it was vulnerable, installing the patch is only one step. Check whether attackers got in and whether they reached other systems through support sessions.
See what investigators found in Zero-Day Vulnerability Gave Attackers Time to Plant Backdoors.
Some Phala Customers Need to Change Their Secrets
Phala says an attacker accessed logs and environment variables from some customer apps. The attacker also stole an admin token from one host and changed certificate settings. Phala says protected keys, customer disks, and host logins were not affected.
All customers must move to a fixed dstack image by November 19. Only customers who received an exposure notice need to change secrets stored in the affected apps’ environment variables.
Find out who needs to upgrade or change secrets in Phala Attack Shows What Confidential Computing Does Not Protect.
Did You Update the PHP Version Your Website Uses?
Updating a website or its plugins does not update PHP itself. Two serious PHP flaws could let an attacker run code without logging in. One attack path involved Apache’s PHP module, before the website’s own code ran.
Install the fixed PHP package from the provider that supplies the PHP version your site uses. Then restart the affected service and c
See which setups and PHP versions are affected in Critical PHP Vulnerabilities Let Attackers Run Code Without a Login.
