INFORMATICS

PHP2Shell – Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619). What You Need to Know and How to Protect Your Servers

On 21 October 2026, the PHP project released an emergency security update addressing two critical vulnerabilities in the PHP core itself. Known in the security community as PHP2Shell, these flaws allow unauthenticated remote code execution (RCE). Both have been rated CVSS v4.0 9.2.

They affect virtually all PHP installations that serve web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest risk is associated with mod_php, where an attacker can trigger the exploit before any application code runs.

How do the vulnerabilities work?

CVE-2026-109618 – RCE via OOM (Out-of-Memory) corruption
When PHP runs out of memory while processing a request (for example during a large multipart file upload), it aborts and begins cleanup. In certain conditions the internal request data structures are only partially initialised. The cleanup routine still treats them as valid, leading to memory corruption that can be leveraged for remote code execution.

CVE-2026-109619 – RCE via stale global state (use-after-free)
Internal state belonging to one request can survive after its memory has been freed. A subsequent request handled by the same worker may use that stale state before PHP resets it. One confirmed attack path involves the session upload-progress feature, which is enabled by default.

Because the bugs live in the PHP engine itself, even a fully patched application (WordPress, Joomla, Drupal, Laravel, etc.) remains vulnerable if it runs on an unpatched PHP version.

What are the risks?

• Complete server takeover (code execution under the privileges of the PHP process)
• Theft of passwords, authentication tokens, API keys and certificates from process memory
• Installation of backdoors, ransomware or cryptominers
• Lateral movement to other services on the same host
• Mass scanning and exploitation already observed in the wild (reported by Amazon Threat Intelligence and others)

Given that PHP powers the majority of websites worldwide, the potential impact is extremely high.

Affected versions and fixed releases

Updating PHP is the only complete fix.

Temporary mitigations (if you cannot upgrade immediately)

1. Set session.upload_progress.enabled = 0 in php.ini
2. On PHP 8.5 also set fatal_error_backtraces = 0
3. Configure pm.max_requests = 1 (PHP-FPM) to reduce the chance of state reuse across requests
4. Restart all PHP workers (Apache, PHP-FPM, etc.)

These measures only reduce risk; they do not eliminate the vulnerabilities.

Recommended actions right now

1. Check your PHP version: php -v
2. Upgrade to the latest patched release in your branch
3. Restart PHP/Apache/Nginx services
4. Monitor logs for suspicious multipart/form-data requests
5. If you use shared hosting, contact your provider and request an immediate update

Sources: Official PHP security advisories (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp), CERT-EU, security research from Wiz, JFrog and Amazon.

Updating PHP should be the top priority for every web server administrator.

Po zalogowaniu tego samego konta Microsoft na kilku komputerach została włączona synchronizacja danych przeglądarki Microsoft Edge. Office sam w sobie nie powinien wymieniać haseł między komputerami, ale logowanie do konta Microsoft może spowodować uruchomienie synchronizacji Edge.

Na każdym komputerze możesz to zablokować.

1. Wyłącz synchronizację Edge

Na komputerze, na którym nie chcesz udostępniać haseł i ulubionych:

1. Otwórz Microsoft Edge.
2. Wpisz w pasku:
   edge://settings/profiles/sync
3. Wyłącz Synchronizacja.

Jeżeli chcesz pozostawić synchronizację niektórych danych, ale bez haseł i ulubionych, wyłącz przynajmniej:

• Hasła
• Ulubione
• Autouzupełnianie
• Historia
• Ustawienia — jeśli również nie chcesz ich współdzielić.

2. Ważne: sprawdź konto używane przez Edge

Wejdź w:

edge://settings/profiles

Sprawdź, czy Edge jest zalogowany na to samo konto Microsoft, którego używasz do aktywacji Office 2024.

Jeżeli jest to wspólne konto firmowe używane na wielu komputerach, to właśnie to jest prawdopodobną przyczyną.

3. Jeżeli chcesz całkowicie rozdzielić komputery

Jeżeli każdy komputer ma mieć własne ulubione, własne hasła i własną historię, najlepszym rozwiązaniem jest:

• Office może być aktywowany zgodnie z licencją na właściwym koncie,
• ale Edge powinien być używany z osobnym kontem/proflem użytkownika albo bez synchronizacji.

Szczególnie w firmie nie polecam używania jednego konta Microsoft jako konta Edge na wszystkich komputerach, ponieważ oprócz ulubionych mogą synchronizować się również zapisane hasła.

4. Jeżeli hasła już się wymieszały

Samo wyłączenie synchronizacji niekoniecznie usunie już pobrane hasła i ulubione z poszczególnych komputerów.

Możemy zrobić to bezpiecznie, tak aby:

• na każdym komputerze zostały jego własne hasła,
• usunąć hasła pochodzące z innych komputerów,
• zatrzymać dalszą synchronizację,
• a jednocześnie nie utracić haseł, które są potrzebne.

Jeśli masz np. 10 komputerów z Office 2024 na jednym koncie Microsoft, można zablokować synchronizację haseł przez zasady grupy Windows (GPO) - administrator centralnie blokuje synchronizację haseł i ulubionych w Edge na wszystkich komputerach. To najlepsze rozwiązanie w środowisku firmowym.

Cyber Attack on MyDr – One of the Largest Data Breaches in Polish History. Detailed Incident Analysis

In August 2026, Poland experienced one of the most serious cybersecurity incidents in the country’s history. The victim was MyDr, a provider of Electronic Medical Records (EDM) software used by thousands of healthcare facilities. According to official confirmations from the Ministry of Digital Affairs and findings of the Joint Cybersecurity Operations Center, unauthorized access affected data relating to nearly 19 million people (approximately 18,814,422 unique PESEL numbers according to the attackers’ claims) and more than 12,000 medical facilities.

Scale and Nature of the Breach

MyDr processes around 3 million visits and 2.7 million e-prescriptions monthly. The historical data (up to April 2024) stored in the company’s systems included, among other things:

• PESEL numbers,
• visit histories,
• prescription and medication information,
• contact details,
• potentially information about medical conditions.

The stolen database is estimated at over 2 TB (up to 2.5 TB according to the attackers). The data is historical — current operations of healthcare facilities, prescription issuance, and patient care were not disrupted. Systems were isolated, and the company is cooperating with authorities.

How the Incident Unfolded

1. Detection and first signals – Around 10 August 2026, MyDr announced it was investigating a security incident. At the same time, individuals claiming to be the perpetrators contacted the cybersecurity site Zaufana Trzecia Strona, providing evidence (screenshots containing data of politicians and journalists).
2. Official confirmation – On 12 August 2026, following a meeting of the Joint Cybersecurity Operations Center, Digital Affairs Minister Krzysztof Gawkowski officially confirmed the scale of the breach as “extraordinary.” The case is being handled by the Central Bureau for Combating Cybercrime, the National Prosecutor’s Office, the Personal Data Protection Office (UODO), special services, and the Ministry of Health.
3. Response – Data is being progressively transferred to the bezpiecznedane.gov.pl portal, where citizens can check whether their information was affected. Immediate freezing of the PESEL number (e.g., via the mObywatel app) is strongly recommended.

How Did the Hackers Gain Access? (Attackers’ Version – Officially Unconfirmed)

According to the account given by the alleged perpetrators to Zaufana Trzecia Strona (not yet confirmed by authorities or MyDr), the initial attack vector was an XXE (XML External Entity) vulnerability related to the handling of PKCS#12 certificates. This allegedly allowed remote code execution (RCE). The attackers then obtained a GitHub API key leading to the system’s source code and subsequently gained access to the infrastructure running on AWS. They also demonstrated control over company tools (Jira, HubSpot CRM) and the ability to send SMS messages from the official company account.

Important note: The above scenario comes solely from the alleged attackers and has not been publicly confirmed by law enforcement or the company. A detailed investigation is ongoing. The motive appears to be financial (medical data is highly valuable on the black market for targeted phishing and identity theft) rather than sabotage.

Consequences and Recommendations

The incident highlights the risks associated with concentrating sensitive medical data with external software providers. Individual medical facilities remain the data controllers, while MyDr acted as a processor. Citizens should:

• check their status on bezpiecznedane.gov.pl,
• freeze their PESEL number,
• exercise heightened caution with emails/SMS related to medical services (phishing risk).

The investigation continues. We will update this article as official findings become available.

Źródła: komunikaty Ministerstwa Cyfryzacji, MyDr, raporty Zaufanej Trzeciej Strony, Business Insider, Spidersweb i inne wiarygodne media (stan na 13 sierpnia 2026).