server
15 articles with this tag
Linux kernel CVE-2026-98432: a network-triggered TCP use-after-free (CVSS 9.8); install the fixed kernel, reboot, and check MPTCP
CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP code, published on October 15, 2026. The kernel project's CNA scores it CVSS v3.1 9.8 (network, no privileges, no user interaction). Researchers at an AI company reportedly demonstrated, in a lab and by their own report, remote code execution as root against a server with a Multipath TCP (MPTCP) listener. BleepingComputer says remote code execution on plain TCP servers has not been shown publicly and no exploitation in the wild has been confirmed, and this site did not find the CVE in CISA's KEV catalog on November 1. Upstream fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10 and later. As of November 1, Debian has fixed kernels, SUSE has some, and Ubuntu and Red Hat list fixes as in progress. Disabling MPTCP alone is not a full fix. This site's conclusion: update internet-facing Linux servers as fixes land, reboot, and use a vendor stop-gap only until then.
What to check after an emergency PHP update: web PHP vs command-line PHP, set -e and diff exit codes, and an intrusion re-check
During the October 2026 response to the critical PHP vulnerabilities, a site this site's operator runs had updated the web PHP, but the command-line PHP used by cron still pointed to an old version. Check web and CLI separately. With set -e, diff and grep return exit status 1 for 'differences found' or 'no match', which stops the script; handle 0, 1 and 2 separately. After patching, run the same intrusion checklist on every server, and settle a suspicious log entry by comparing live files with the known-good deployed copy.
VMware ESX CVE-2026-41709 (CVSS 2.7): CISA lists the low-severity logging flaw as exploited; patch the whole VMSA-2026-0006 and check your hosts
CVE-2026-41709 is an insufficient logging flaw in VMware ESX (CVSS 2.7, Low): an attacker who already has administrator access can perform certain operations without them being recorded in the logs. Broadcom fixed it in advisory VMSA-2026-0006 on July 29, 2026, with no workaround. On October 28, 2026 (US time) CISA added it to its Known Exploited Vulnerabilities (KEV) catalog, with a due date of November 11 for US federal agencies. A security company's threat report says a China-linked group used it as a zero-day in several intrusions at US organizations, as late as early 2026, and SecurityWeek describes the purpose as reducing audit trail visibility; this site has not verified that report independently. The flaw gives no entry by itself, but it means logs from an affected host may not show what an intruder did. The same advisory includes two vCenter flaws rated 9.8, one of which (CVE-2026-59310) CISA listed as exploited on August 18, so patching only the ESX flaw leaves the entry points open. This site's conclusion: update ESX and vCenter to the fixed builds for the whole advisory, send host logs to a separate server, and look for signs of compromise instead of trusting the logs alone.
Linux kernel Fragnesia (CVE-2026-46300): CISA lists it as exploited with a Oct 31 deadline; patch PHP and the kernel, then reboot
CVE-2026-46300, nicknamed Fragnesia, is a flaw in the Linux kernel that lets a low-privileged local user gain root (CVSS v3.1 7.8, local attack vector). When the kernel moves data fragments between network buffers it can lose a marker that says the data is shared with a file in memory, and the IPsec ESP code can then decrypt over the cached copy of a read-only file. The kernel project published the CVE on May 23, 2026, and fixes are in kernel 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 and 7.0.10 and later. On October 28, 2026 (US time) CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on evidence of active exploitation, with a due date of October 31 for US federal agencies. CISA's description says it can be chained with the PHP flaws CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root. A security company reported that this chain was used against 25 servers (mostly firewalls), and SecurityWeek repeated the report; this site has not independently verified the numbers. Ubuntu, Red Hat and Debian have shipped fixed kernels, and a kernel update takes effect only after a reboot. This site's conclusion: if you run PHP sites on Linux, update PHP and the kernel, reboot, and check for webshells.
Nextcloud built-in Collabora CODE server CVE-2026-110447 exploited: who is affected and what to do
On October 14, 2026, the Collabora Online developers disclosed CVE-2026-110447, an unauthenticated OS command injection vulnerability in the Nextcloud app Collabora Online - Built-in CODE Server (app ID richdocumentscode). Through the app's proxy.php, commands can run as the web server user. The condition is that the built-in CODE server is not running, which can happen after a container restart, an upgrade or a crash. Versions before 26.4.303 are affected; 26.4.303 was released on September 11. The developers say disabling the app does not prevent the problem and ask users to update or remove it. On end-of-life Nextcloud 29 and earlier, update Nextcloud or remove the app. The developers say standalone Collabora Online servers, Docker images, RPM/DEB packages and Nextcloud All-in-One are not affected. The CVSS v4.0 score is 9.2. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on October 23 with a due date of October 26. Users reported attacks from around September 10 in the developers' repository, and according to press reports web shells were planted. This site's conclusion: if the built-in CODE app is installed, even disabled, check its version today, update or remove it, then check for traces since September 10.
GitLab CVE-2026-110264 (CVSS 10.0) and the exploited CVE-2026-97229: how to check and update a self-managed GitLab
On October 21, 2026, GitLab released critical patch versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 for Community Edition (CE) and Enterprise Edition (EE). The most severe flaw, CVE-2026-110264 (CVSS 10.0), is an integer overflow when compiling a specially crafted regular expression that, under certain conditions, could allow an unauthenticated user to execute arbitrary code on the GitLab server. Almost every version from 7.0 onward is affected. On October 29, CISA added a sister flaw, CVE-2026-97229 (CVSS 10.0, CWE-190), to its Known Exploited Vulnerabilities (KEV) catalog with a due date of November 1. It is the same kind of bug (an integer overflow in the CI/CD regular expression compiler, reachable by an unauthenticated user), GitLab fixed it earlier on October 12 in 19.4.2, 19.3.5 and 19.2.8, and it affects only 19.2.0 to 19.2.7, 19.3.0 to 19.3.4 and 19.4.0 to 19.4.1. Anyone still below 19.4.2, 19.3.5 or 19.2.8 is exposed to an exploited flaw. Upgrading to the versions recommended here (19.5.1, 19.4.3, 19.3.6, 19.2.9) also fixes CVE-2026-97229. GitLab.com is already patched; self-managed installations need to upgrade. The same October 21 release fixes two High-severity flaws (CVSS 8.2 and 7.5) and others, but those fixes ship only in the 19.3.6, 19.4.3 and 19.5.1 lines. The root cause is in Ruby's regular expression engine (Onigmo), and Ruby released 4.0.9, 3.4.12 and 3.3.13 on October 23. Applications that compile a regexp from attacker-controlled strings are affected, and Regexp.timeout does not protect against the bugs. GitLab's notices do not say CVE-2026-110264 has been exploited, and it is not in KEV as of October 30. Alpine Linux reported on its own GitLab an attempted attack through CVE-2026-97229 on October 20 and 21, and that upgrading GitLab alone (to 19.3.6) did not close the flaw because the fix also needed a patched Ruby; it rebuilt the instance and found no evidence that attacker code ran. This site's conclusion: upgrade self-managed GitLab today after checking the required upgrade stops, end up on 19.3.6 or later, and if you build GitLab yourself or run your own Ruby, check that Ruby is 3.3.13, 3.4.12 or 4.0.9 or later too. Ruby applications should move to a fixed Ruby and stop building regexps from user input.
SiteGuard Server Edition CVE-2026-106931 exploited: who is affected and what to do
On October 14, 2026, EG Secure Solutions disclosed CVE-2026-106931, an OS command injection vulnerability in the statistics feature of SiteGuard Server Edition, its host-based web application firewall (WAF), and said exploitation has already been confirmed. Exploitation may allow arbitrary OS commands to run with root or SYSTEM privileges on the server running the product. Affected are Ver2.20 and later with the statistics feature enabled (it is enabled by default): the Apache, Nginx and IIS editions before Ver8.00 Update5, and the FreeBSD Apache and Nginx editions before Ver7.00 Update6. The IIS edition Ver3.10 through Ver4.00 Update4 is not affected. The fixes are Ver8.00 Update5 and Ver7.00 Update6; for systems that cannot be upgraded, a patch is available, including for end-of-support versions. The vendor rates the flaw as local attack vector with low privileges required (CVSS v3.0 7.8, v4.0 8.5). JPCERT/CC issued an alert, saying it has confirmed the product is widely used in Japan, and that disabling the statistics feature avoids the issue. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on October 20 with a due date of October 23. This site's conclusion: if you run Server Edition, check the version and the statistics feature today, save the diagnostic data before updating, then apply the fixed version or the patch.
[Breaking] PHP flaws CVE-2026-109618 and CVE-2026-109619 now exploited, added to CISA's KEV catalog: update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now
On October 21, 2026, the PHP security team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical vulnerabilities that can allow unauthenticated remote code execution (RCE), and urged all users to update immediately. CVE-2026-109618 involves out-of-memory handling and CVE-2026-109619 involves stale internal state surviving between requests; both are rated 9.2 under CVSS v4.0. All PHP installations serving web requests are at risk (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). The team considers mod_php the highest risk, citing a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs. PHP 8.1 and older get no official update; the team provided minimal source backports for 7.4, 8.0 and 8.1. Linux distributions received the patches in advance. There is no complete mitigation; updating is the only safe choice. On October 22, Japan's IPA and JPCERT/CC issued alerts and JVN published JVNVU#99905564. CISA, which had not observed exploitation when it first published its alert, added both flaws to its Known Exploited Vulnerabilities (KEV) catalog on October 26, with an October 29 deadline for US federal civilian agencies. According to media reports, a security researcher's honeypots running unpatched PHP 8.4.26 under mod_php saw successful remote code execution on October 24. A major cloud provider's honeypots had seen exploitation attempts from October 17, four days before disclosure. As far as this site could find, no break-in outside honeypots had been made public as of October 27. Most major Japanese shared-hosting providers have announced that the fix is applied, but some, such as KAGOYA, have not. On October 23, the PHP team disclosed a third issue (CVE-2026-115560) that the October 21 releases do not fix. It can lead to code execution only under a specific combination of configuration and application code; the team calls it unlikely in practice, will ship the fix and a full advisory with the next regular release, and recommends setting session.upload_progress.enabled=0 until then. Affected versions and a CVSS score have not been published, and no exploitation has been reported. As of October 29 (checked on php.net), no fixed release for this issue was out. On October 28, CISA also added the Linux kernel flaw CVE-2026-46300 to KEV (October 31 deadline for US federal agencies) and said it can be chained with these two flaws to implant PHP webshells and run commands as root. This site's take: exploitation is now confirmed, so confirm whether you or your provider updates PHP for each site and move to the fixed version today. Also check logs from October 17 onward for signs of a break-in. On shared hosting, check your provider's completion notice on its official website.
Does website security affect SEO? Vulnerabilities, hacked sites, HTTPS and rankings, sorted out from Google's official documentation
Google does not list vulnerabilities as a ranking factor. The damage comes when one is exploited. Hacked spam pages earn a 'This site may be hacked' label in results, malware or phishing triggers a 'Dangerous site' warning in Chrome (other browsers show their own Safe Browsing warnings), and sites that violate the spam policies may rank lower or not appear at all. HTTPS was announced in 2014 as a 'very lightweight' signal, and Google's current page experience documentation says that beyond Core Web Vitals, other page experience aspects don't directly help a site rank higher. This site's view: for SEO, spend your time on not getting hacked and on noticing quickly if you are, not on raising a security score.
How to check if your website or server was hacked: step-by-step checks for shared hosting, WordPress and a VPS, and what to do first if you find something
Checking a site for intrusion means looking at both the signs visible from outside and the traces left inside. Signs: Search Console's Security issues report, a 'This site may be hacked' label in search, a notice from your host, unknown admins, redirects that happen only on mobile or from search. Traces: admin users, modified core files (wp core verify-checksums), login history, authorized_keys, cron, listening ports, recently changed files. This site's view: finding nothing does not prove you are clean. If you do find something, preserve evidence before cleaning, rotate every credential from a clean device, restore from a pre-intrusion backup or rebuild, close the entry point, and only then request a review.
Did you leave a secret file in a public directory? Audit your webroot
Anything in your webroot is fetchable by URL by anyone. A leftover token/credential JSON, .env, or backup means instant exposure — and if it came from a shared template, every site has the same file. Fix: put only publicly-shareable things in the public dir, keep secrets outside the webroot at perms 600, and once you find one, audit every site and host.
Security inventory: 7 checks people running several servers overlook
For solo/small operators, incidents come less from missing controls than from untracked state. The boundary is the PC holding your keys. Prioritize 2FA by which account can recover the others (email first), list which SSH key opens which server and delete duplicates, unused keys and leftover registrations, remove plaintext passwords from the cloud, remediate reversibly one at a time, and keep secrets out of the ledger. Inventory before adding tools.
Self-hosted Git vs GitHub: which is actually more secure?
Self-hosting Git doesn't make you 'more secure' — it relocates the risk. The accidental-public-exposure class disappears, but patching the server, backups, and pre-commit secret detection move onto you. The right call if you keep doing that work; worse than GitHub if you neglect it. This site's view: self-hosting only works bundled with its compensating controls.
SSH key least privilege: keep production root keys off ephemeral environments that can be compromised
Registering a root key into production from an ephemeral, compromisable environment (GPU pod, CI runner, throwaway VM) means that the moment the environment is compromised, an attacker gets root on production. Fix: no root keys on ephemeral environments; remove keys when unused; if needed again, use a non-root user plus a command-restricted key that limits the key to one operation. Treat a reused key as your most critical asset, and never build a setup where one leaked key opens every server.
Keeping .env off the public web on shared hosting
The main fix: app body outside the docroot, only public/ exposed. Block access with .htaccess first, make it permanent by restructuring, then self-check. This site's view: this isn't one person's slip but a dangerous layout that became standard across the industry — fix it with process, not vigilance. bootstrap-redirect beats symlink.