Ravindra BagaleCourses & study guides मराठी Track your progress

9. PHP, LAMP and LEMP Step by Step

9.8 Secure PHP Settings

By Last updated:

PHP chalu zala – aata php.ini madhe kahi mahatvache badal. File cha path php --ini ne kalto (Amazon Linux: /etc/php.ini, Ubuntu: /etc/php/8.x/fpm/php.ini kiwa /etc/php/8.x/apache2/php.ini).

Setting Secure value Why
expose_php Off Hides the X-​Powered-​By: PHP/​8.​x header
display_errors Off Errors with paths and SQL must not reach visitors
log_errors On Errors go to the log instead
allow_url_include Off Blocks remote file inclusion
upload_​max_​filesize / post_max_size As small as the app needs Limits abuse of uploads
session.​cookie_​httponly 1 JavaScript cannot read the session cookie (limits XSS damage)
session.​cookie_​secure 1 (with HTTPS) Cookie only sent over HTTPS 
php --ini | grep "Loaded Configuration"
sudo sed -i 's/^expose_php = On/expose_php = Off/' /etc/php.ini              # Amazon Linux
sudo sed -i 's/^display_errors = On/display_errors = Off/' /etc/php.ini
sudo service php-fpm restart                                                 # Ubuntu: php8.3-fpm
curl -I http://localhost/index.php | grep -i x-powered-by                    # should print nothing

Why this matters for security

Verbose PHP errors are a gift for attackers: a single SQL error message can reveal the table name and query structure, making SQL injection much easier (error-based SQLi). Production servers log errors; they never display them.

Ravindra Bagale's Tip

display_errors = On was left on in development and went to production as it was – this happens in many projects. Keep this line in your deploy checklist: "display_errors Off, expose_php Off, info.php deleted". Very simple, but very important.

Practice task

Apply the settings from the table on one server, restart PHP-FPM, and confirm with curl -I that the X-Powered-By header is gone.

Thodkyaat sangaycha tar

  • Dynamic = server runs code (PHP) and queries a database for each request.
  • Apache runs PHP via mod_php or PHP-FPM; Nginx always via PHP-FPM (FastCGI socket).
  • LAMP = Linux + Apache + MySQL/MariaDB + PHP; LEMP = same with Nginx.
  • Amazon Linux: yum, httpd, mariadb105-server, php-fpm. Ubuntu: apt, apache2, mysql-server, libapache2-mod-php or php-fpm.
  • 502 = PHP-FPM not running or wrong socket. Delete info.php after testing.
  • Prepared statements stop SQL injection; htmlspecialchars() stops XSS; display_errors Off in production.

Samjla ka? Stack tayar – aata database khol shikuya. Aata pudhe jaauya MySQL kade!

Extended teaching notes

Why this lesson matters

Use this lesson to strengthen systems you own: understand the risk, practise safely in a lab, then write and apply the fix.

Apply the fix across stacks

Same class of bug, same idea in every language.

Java / Spring Boot

Parameterise queries, encode output, CSRF tokens, limited Actuator, dependency scanning.

ASP.NET Core

EF Core / parameterised SQL, Razor encoding, HTTPS, Data Protection.

Node.js / Express

helmet, parameterised SQL, npm audit, avoid eval and shell concat.

Python / Django / Flask / FastAPI

ORM, autoescape, pip-audit, Bandit; never shell=True with user input.

PHP / Laravel

PDO/Eloquent, Blade escaping, composer audit.

Go / Ruby

database/sql placeholders / ActiveRecord; html/template / ERB escaping; govulncheck / Brakeman.

nginx / Apache / Tomcat

Hide versions, TLS, security headers, least-open ports.

MySQL / PostgreSQL / MongoDB / Redis

Private networks, auth on, least-privilege users, no 0.0.0.0/0.

AWS / Azure / GCP

Roles not long-lived keys, private data stores, cloud audit logs on.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.

Real incident: PHP2Shell – two critical PHP flaws let attackers run commands on web servers without a login, and governments took websites offline (Oct 2026)

1. What happened

PHP is the language that builds web pages on the server. WordPress, Drupal, Joomla and many control panels run on it. In this lesson you set PHP up and made its settings safe.

  • On 21 October 2026, the PHP team released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. These fix two critical flaws: CVE-2026-109618 and CVE-2026-109619. Together they are called "PHP2Shell".
  • Both flaws allow remote code execution (RCE) without a login. That means a stranger on the internet can make your server run their commands. Each flaw has a CVSS v4.0 score of 9.2.
  • PHP says every PHP install that serves web pages is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for mod_php, where one request can start the attack before any of your PHP code runs.
  • Researchers from Calif, Wiz and OpenAI found the flaws with the help of AI tools. Details leaked on social media on 20 October, so the PHP team had to rush its warning.
  • Amazon saw an attack attempt on its trap servers (honeypots) on 17 October, four days before the public warning. After the fix came out, Amazon said PHP2Shell is now "being broadly exploited in the wild".
  • Many sites went offline as a safety step. Finland shut its government public web services for a while. The Dutch cyber security agency took its own website offline. Wikimedia took some systems down. The UK NCSC said: patch now, or take the system offline until you can. India's CERT-In also issued a critical warning.
  • PHP 8.1 and older no longer get fixes from the PHP project. You need a fix from your Linux vendor, or a move to a supported version.

2. How the hack happened (public reporting only – high-level)

  1. Attackers scan the internet for servers that run PHP. They do not need to pick a victim. Any public PHP page is enough.
  2. They send one specially shaped form request to any PHP page. No login is needed. Datadog showed that even a page that only prints one short reply is enough.
  3. The request makes PHP stop in the middle of its work (for example, it runs out of memory). Some of PHP's own data is left half-ready.
  4. PHP then cleans up after the failed request, or the next request on the same worker uses old leftover data. PHP trusts this broken data.
  5. The attacker's command then runs as the web server user (like apache or www-data). From there they can read files, read database passwords from config files, or leave a hidden backdoor.
  6. Your login page, your input checks and your firewall rules inside the app do not help, because all this happens before your code runs.

3. How to stop it / defend (this lesson: secure PHP settings)

  • Patch first. It is the only full fix. Check the version with php -v. Update with your package manager (sudo dnf update 'php*' on Amazon Linux, sudo apt update && sudo apt upgrade on Ubuntu). Then restart every worker: sudo service php-fpm restart (Ubuntu: php8.3-fpm), and sudo service httpd restart (Ubuntu: apache2) if you use Apache.
  • Check the PHP that serves the web, not only the command line. The web server can use a different PHP. Open a test page with phpinfo() on your own lab server, read the version, then delete the test page.
  • If you cannot patch today, take the site offline, as the NCSC advised. As a short-term extra step only, the PHP team lists php.ini settings that block some attack paths: session.upload_progress.enabled = 0, a small post_max_size (8M if you have no uploads, 32M if you do) and upload_max_filesize smaller than post_max_size. Put them in php.ini or the FPM pool file, not in ini_set() or .user.ini, and restart. These settings do not make you safe.
  • Hiding errors does not stop this bug. display_errors = Off is still right for production, but the PHP team says hiding errors with display_errors, error_reporting or @ does not help here.
  • Limit the damage. Run PHP as its own low-power user. Give the website's database user only the rights it needs. Keep secrets out of files the web user can read when you can.
  • A WAF in front helps for a few days. Cloudflare added rules, but its CTO called them a "STOPGAP only".

4. How to take care so it won't happen again (checklist)

  • [ ] Make a list of every place PHP runs: servers, containers, control panels and products that hide PHP inside.
  • [ ] Patch internet-facing servers in hours, not weeks, when a critical flaw is out.
  • [ ] After patching, restart every worker and rebuild container images.
  • [ ] Look at logs from 17 October onwards: very large form requests, "Allowed memory size ... exhausted ... in Unknown on line 0" errors, and any shell started by the web server user.
  • [ ] Move off PHP 8.1 and older. Plan upgrades before support ends.
  • [ ] Keep production php.ini safe: display_errors Off, expose_php Off, small upload limits, settings that apps cannot override.

Source: PHP security advisory "Critical remote code execution vulnerabilities, update now" on php.net, 21 October 2026; Amazon AWS Security Blog, CJ Moses, "Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot", 21 October 2026; BleepingComputer, Sergiu Gatlan, "PHP ships emergency patches for critical PHP2Shell flaws", 21 October 2026; Datadog Security Labs, "PHP2Shell - Critical vulnerabilities in PHP", 21 October 2026; BBC News, "Websites taken down worldwide as critical PHP cyber-security update issued", 21 October 2026; Reuters (via CNBC), "Government websites go dark as software flaw sparks security scramble", 21 October 2026; Business Today, 22 October 2026 (CERT-In note).

Check if you're safe: Is My Website Hacked? · Website Security Checklist