Search

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 said it had not observed exploitation as of its publication. No confirmed break-in had been announced as of 04:45 UTC on October 22. Many shared-hosting providers have announced that the fix is applied, but some have not yet. This site's take: confirm whether you or your provider updates PHP for each site and move to the fixed version today. On shared hosting, check your provider's completion notice on its official website.

PHP object injection (CWE-502) in Mirasvit Full Page Cache Warmer for Magento 2 before 1.11.12 reaches unauthenticated RCE. CVSS 9.3. The main fix is updating to 1.11.12+. The root rule: never deserialize untrusted data.

Unauthenticated local file inclusion in WordPress core 4.7–7.1.1 (CWE-98), leading to RCE when theme and server conditions line up. Fixed 22 September (7.1.2 and every branch back to 4.7); CISA added it to KEV on 25 September. This site's view: an EPSS of 3% does not matter once it is in KEV. Update, and also turn off PHP's register_argc_argv to remove the server-side condition RCE needs.

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.

The danger in deserialization is not that bad values arrive; it is that some formats let external data decide which type of object to construct. So the damage does not stop at corrupted data — OWASP lists denial of service, access control bypass and remote code execution. Two defenses: switch to a pure data format so nothing chooses types for you, and sign serialized messages so unsigned ones are never restored. And some mechanisms cannot be made safe by configuration at all; the only fix is not using them.

Session fixation makes a victim use an attacker-known session ID, then impersonates them after they log in with it. The main defense: regenerate the session ID on login (and on privilege change). Don't accept IDs from the URL, and set HttpOnly/Secure/SameSite on cookies.

On October 16, 2026 (UTC), Rank Math announced that Rank Math PRO v3.0.123, the paid version of its WordPress plugin, contained malware for a limited number of users who downloaded it between 20:02 UTC on October 15 and 07:12 UTC on October 16. The malware could compromise a site if the plugin was activated, and could recreate its hidden backdoor whenever the site was visited. The company removed the affected files and released a clean v3.0.124. The free version distributed on WordPress.org is not affected. Neither the number of affected users nor how the malware got into the files has been disclosed. As of October 20, the last change to the notice was on October 19, when a note that the free version is not affected was added. This site's conclusion: treat any site that activated a copy of 3.0.123 obtained during the affected window as compromised, and either restore from a backup taken before the window or delete the whole plugin folder and clean up in the order the company gives. Either way, change every credential the site could read.

WordPress has the largest share, so it's the biggest target, but the ways in are predictable (plugin/theme vulnerabilities, skipped updates, weak admins, exposed admin panels). This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) per-area guidance — automatic updates, minimizing plugins/themes, strong admin + 2FA, reducing admin exposure (xmlrpc/REST enumeration/file editing), wp-config and secrets, file permissions, HTTPS/backups, PHP/dependency updates, and (3) a self-verification checklist. Defensive only — no attack steps.

A practical guide to storing passwords safely on the server. Understand why plaintext, encryption, and raw hashes all fail, then converge on one answer: a per-user salt plus a deliberately slow hash (Argon2id recommended, bcrypt/scrypt as alternatives). Don't roll your own — use the standard function, raise the cost over time, and migrate weak hashes by re-hashing on login.

On September 20, 2026, GMO Internet, Inc. announced that on some hosting servers (web servers) of its ConoHa WING rental hosting service, a third party had gained unauthorized access to the web server areas of some customers and installed a malicious program. 426 accounts are affected, and the data concerned is 'data stored in customers' web server areas'. The access and installation began on September 3; the company detected it on September 16, and on September 18 identified the cause and scope and removed the programs. It says it has identified the cause but has not disclosed it. Member, contract and payment data are managed in a separate environment and were not leaked, it says. The notice does not say whether data in the web server areas was taken. Affected customers were contacted individually at their registered email address, and customers who were not contacted are not affected. There was no follow-up notice as of October 15. This site's take: first check whether you received an individual email and, if so, follow its instructions. Then treat the credentials kept in your web server area (the database password in wp-config.php, API keys in .env and so on) as read and change them, and look for files, administrators and scheduled jobs added since September 3.

A provider-side compromise cannot be blocked by customer settings, so the defense shifts from prevention to limiting how much you can lose. The 10 September investigation results established the part that matters most: unauthorized access to the sales management system occurred between April 2023 and March 2026, the affected hosting accounts rose from 583 to 951, and some initial passwords were not hashed. This site's view: treat everything on shared hosting as readable, push secrets, credentials and backups outside the provider, and change any initial password you are still using today.

Laravel's defaults are strong; production incidents come from config and operations. This is a working reference: (1) a priority-ordered hardening checklist (P0–P2), (2) a table of dangerous defaults, (3) per-area guidance — secrets/APP_KEY, production config (APP_DEBUG/caching), authorization (Policy/Gate, Mass Assignment), injection/output (Eloquent binding, Blade), sessions/CSRF/cookies, uploads, HTTPS/headers/rate limiting, Composer dependency CVEs, and (4) a self-verification checklist. Defensive only — no attack steps.

iCagenda (Joomla events-calendar extension) 3.2.1–3.9.14 and 4.0.0–4.0.7 has an unauthenticated arbitrary file upload → RCE (CVSS 10.0, in CISA KEV). Access control on the public event-registration form's attachment handler was reportedly enforced only at the view layer, not the controller. The main fix is updating to 3.9.15 or 4.0.8, plus a compromise check. The durable defense is designing out the 'unauthenticated upload → RCE' pattern.

SP Page Builder for Joomla (by JoomShaper) ≤ 6.6.1 has an unauthenticated arbitrary file upload → RCE (CVSS 10.0, in CISA KEV). The custom-icon upload reportedly ran no auth or type validation. The main fix is updating to 6.6.2, plus a compromise check (rogue admins, web shells). The durable defense is designing out the 'unauthenticated upload → RCE' pattern.

Whatever framework you use, the *types* of weakness attackers hit are largely the same (access control, secrets, injection, dependency CVEs, misconfiguration). What differs is each framework's 'dangerous defaults' and 'the spot most often targeted.' This site provides, per framework, the default pitfalls and the hardening steps. Start with the chapter for the stack you actually use.

Password hashing means storing a password as a one-way, non-reversible transform. Never store plaintext. Unlike encryption you can't decrypt it back — that's the point. But plain MD5/SHA-256 falls to rainbow tables and brute force. The fix: a per-user salt plus a deliberately slow hash (bcrypt/Argon2/scrypt). Don't roll your own — use the standard function.

A salt is a random, per-user value added before hashing a password. The same password then stores differently for every user, which defeats precomputed rainbow tables and stops one cracking run from breaking many accounts. A salt is not secret — store it alongside the hash. bcrypt/Argon2 add one automatically.

SQLi is when input is read as 'part of the command' rather than data, changing a query's meaning and leading directly to read/alter/delete. The main defense is to stop string-concatenating SQL and pass values via placeholders (prepared statements).

The cause: the whole app sat under the web root; only public/ should be visible. Fix in three steps — a temporary .htaccess block, rotate keys, restructure — then prevent it with process.

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.

Vulnerability work isn't done when you 'fix it.' Done = 1) scan, 2) fix, 3) isolate/hand off, 4) monitor. Until monitoring (daily change-detection) is in place, it's incomplete — dependencies turn vulnerable again tomorrow. A perfect fix that the next deploy overwrites is worth zero. Small teams stay safe with two disciplines: automated change-detection and 'local→push→deploy.'

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.