Amazon Linux 2023 ships PHP 8.4 in its own amazonlinux repository, so you can install PHP 8.4 on Amazon Linux 2023 without Remi or any third-party repo. The part that bites people is release locking. An AL2023 instance only sees packages from the release it booted with, so a plain update on an older AMI can leave PHP on a build that is still exposed to PHP2Shell, and nothing in the update output tells you so.
The steps below move the system to the newest release, install PHP 8.4 with the common extensions, prove the build is patched, and serve a test page through Apache and PHP-FPM. Every command below was run as a sudo user on a fresh Amazon Linux 2023 test system (not EC2) with PHP 8.4.27 in October 2026, except the reboot and the security group change, and the output blocks come from those runs.
Update Amazon Linux 2023 to the latest release
AL2023 pins every instance to a dated release (for example 2023.12.20260930), and a plain dnf upgrade only pulls fixes published inside that release. Moving to the newest release is a deliberate step, because AL2023 never changes release on its own: on our test system a plain update printed “Nothing to do” while PHP fixes sat in a newer release. Before upgrading, check whether someone pinned the release in dnf’s variables file, because a pin there wins over the release lock:
cat /etc/dnf/vars/releaseverOn a default system the file doesn’t exist, which is what you want:
cat: /etc/dnf/vars/releasever: No such file or directoryIf it prints a date instead, dnf stays on that release no matter what else you do. We wrote 2023.12.20260930 into it on a box already upgraded to 2023.12.20261021, and dnf went back to offering PHP 8.4.25 until the file was deleted. Remove the pin with sudo rm /etc/dnf/vars/releasever, then run the upgrade with --releasever=latest so the packages you install next come from the newest release:
sudo dnf upgrade --releasever=latest -yOn our test system this moved system-release from 2023.12.20260930 to 2023.12.20261021, and later plain dnf runs stay on the new release because the lock moves with that package. Release upgrades often bring a newer kernel, so reboot for the system to run on it.
sudo systemctl rebootOnce the instance is back, log in again and confirm the release, which is the first thing we check on any AL2023 server before trusting its package versions:
rpm -q system-releaseThe release date in the package name should be the newest one Amazon has published:
system-release-2023.12.20261021-0.amzn2023.noarchAn older date here means the upgrade didn’t take, so check the pin file again before going further.
Install PHP 8.4 on Amazon Linux 2023
PHP 8.4 and its extensions live in the amazonlinux repository, and each extension is a separate package, so you pick extensions one by one instead of pulling a bundle. Search the repository to see what’s available.
sudo dnf search php8.4The search lists every PHP 8.4 package the repository carries:
========================= Name Exactly Matched: php8.4 =========================
php8.4.x86_64 : PHP scripting language for creating dynamic web sites
============================= Name Matched: php8.4 =============================
php8.4-apcu-panel.noarch : APCu control panel
php8.4-bcmath.x86_64 : A module for PHP 8.4 applications for using the bcmath library
php8.4-cli.x86_64 : Command-line interface for PHP 8.4
php8.4-common.x86_64 : Common files for PHP 8.4
php8.4-dba.x86_64 : A database abstraction layer module for PHP 8.4 applications
php8.4-dbg.x86_64 : The interactive PHP 8.4 debugger
php8.4-devel.x86_64 : Files needed for building PHP 8.4 extensions
php8.4-embedded.x86_64 : PHP 8.4 library for embedding in applications
php8.4-enchant.x86_64 : Enchant spelling extension for PHP 8.4 applications
php8.4-ffi.x86_64 : Foreign Function Interface
php8.4-fpm.x86_64 : PHP 8.4 FastCGI Process Manager
php8.4-gd.x86_64 : A module for PHP 8.4 applications for using the gd graphics library
php8.4-gmp.x86_64 : A module for PHP 8.4 applications for using the GNU MP library
php8.4-intl.x86_64 : Internationalization extension for PHP 8.4 applications
php8.4-ldap.x86_64 : A module for PHP 8.4 applications that use LDAP
php8.4-mbstring.x86_64 : A module for PHP 8.4 applications which need multi-byte string handling
php8.4-modphp.x86_64 : PHP 8.4 module for Apache HTTP Server
php8.4-mysqlnd.x86_64 : A module for PHP 8.4 applications that use MySQL databases
php8.4-odbc.x86_64 : A module for PHP 8.4 applications that use ODBC databases
php8.4-opcache.x86_64 : The Zend OPcache
php8.4-pdo.x86_64 : A database access abstraction module for PHP 8.4 applications
php8.4-pecl-apcu.x86_64 : APC User Cache
php8.4-pecl-apcu-devel.x86_64 : APCu developer files (header)
php8.4-pecl-igbinary.x86_64 : Replacement for the standard PHP serializer
php8.4-pecl-igbinary-devel.x86_64 : Igbinary developer files (header)
php8.4-pecl-memcached.x86_64 : Extension to work with the Memcached caching daemon
php8.4-pecl-msgpack.x86_64 : API for communicating with MessagePack serialization
php8.4-pecl-msgpack-devel.x86_64 : MessagePack developer files (header)
php8.4-pecl-redis6.x86_64 : PHP extension for interfacing with key-value stores
php8.4-pgsql.x86_64 : A PostgreSQL database module for PHP 8.4
php8.4-process.x86_64 : Modules for PHP 8.4 script using system process interfaces
php8.4-snmp.x86_64 : A module for PHP 8.4 applications that query SNMP-managed devices
php8.4-soap.x86_64 : A module for PHP 8.4 applications that use the SOAP protocol
php8.4-sodium.x86_64 : Wrapper for the Sodium cryptographic library
php8.4-tidy.x86_64 : Standard PHP 8.4 module provides tidy library support
php8.4-xml.x86_64 : A module for PHP 8.4 applications which use XML
php8.4-zip.x86_64 : ZIP archive management extensionOPcache and the PECL extensions (APCu, Redis, Memcached) are in that list but not in the install line below, so add opcache to the braces if a production site needs bytecode caching. The line installs PHP 8.4 on Amazon Linux 2023 with the standard extensions and PHP-FPM, which is how Apache runs PHP later in this guide.
sudo dnf install -y php8.4-{bcmath,cli,common,dba,dbg,devel,ffi,fpm,ldap,pgsql,mysqlnd,gd,mbstring,tidy,xml,zip}On a fresh system dnf pulled in 181 packages. php8.4-devel is only needed to build PECL extensions and php8.4-dbg is the phpdbg debugger, so you can drop both from the braces on a production web server. Check the PHP version:
php --versionThe CLI reports the Amazon Linux build and its build date.
PHP 8.4.27 (cli) (built: Oct 19 2026 14:38:59) (NTS gcc x86_64)
Copyright (c) The PHP Group
Built by Amazon Linux
Zend Engine v4.4.27, Copyright (c) Zend Technologies8.4.27 is the first PHP 8.4 build with the PHP2Shell fix. If you see a lower 8.4 number here, the system is still on an older release, so go back to the release upgrade or follow the next section before you put a site on this server.
Check for PHP2Shell (CVE-2026-109618, CVE-2026-109619)
PHP2Shell is the name for two critical remote code execution bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0 in PHP’s pre-announcement. Upstream fixed them on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (see the PHP security advisory). Amazon Linux 2023 already ships the fixed PHP 8.4 build as 8.4.27-1.amzn2023.0.1 under advisory ALAS2023-2026-3303, but only from release 2023.12.20261021 onward. An instance still locked to an older release cannot see it.
Amazon moved to the fixed upstream version, and its changelog only says “Package updated to 8.4.27” without naming the CVEs, so the package version is the check. That’s simpler than on Ubuntu or Debian, where a backported fix keeps the old version number and only the changelog tells you. On AL2023, anything lower than 8.4.27 is vulnerable:
rpm -q php8.4-commonA patched server prints the 8.4.27 build.
php8.4-common-8.4.27-1.amzn2023.0.1.x86_64You can also ask the repository which advisory you’re missing. Keep --releasever=latest in this command. When we ran the plain dnf updateinfo query on a server locked to an older release, it printed nothing at all while PHP 8.4.25 was installed, which reads like a clean bill of health, so the flag is the whole point of the check.
sudo dnf --releasever=latest updateinfo list --cve CVE-2026-109618 --cve CVE-2026-109619A patched server prints only the metadata line, so any ALAS line in the output means the fix is waiting for you. A vulnerable server lists ALAS2023-2026-3303 for every installed PHP package, and the version at the end of each line is the build that fixes it. This is the output from a server still on release 2023.12.20260930:
Last metadata expiration check: 0:00:25 ago on Thu Oct 22 19:50:23 2026.
ALAS2023-2026-3303 Important/Sec. php8.4-bcmath-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-cli-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-common-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-dba-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-dbg-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-devel-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-ffi-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-fpm-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-gd-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-ldap-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-mbstring-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-modphp-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-mysqlnd-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-pdo-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-pgsql-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-tidy-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-xml-8.4.27-1.amzn2023.0.1.x86_64
ALAS2023-2026-3303 Important/Sec. php8.4-zip-8.4.27-1.amzn2023.0.1.x86_64If you followed the release upgrade at the top of this guide, rpm -q already shows 8.4.27 and you can move on to the Apache section. The rest of this section is for an existing server that still runs an older build, and we tested it on a server locked to release 2023.12.20260930. The full fix is the release upgrade, which moves the whole OS (85 packages in our run, kernel included), so take an EBS snapshot or an AMI of the instance, or try it on staging, first:
sudo dnf upgrade --releasever=latest -yIf you can’t move the whole OS today, limit the upgrade to the PHP packages. The quotes stop the shell from expanding the glob:
sudo dnf upgrade --releasever=latest -y 'php8.4*'In our run that upgraded 18 packages to 8.4.27 and left system-release on 2023.12.20260930, so the next plain dnf upgrade still can’t see fixes published later, and the full release upgrade stays on your list. The ALAS advisory suggests dnf update php8.4 --releasever 2023.12.20261021, but on a server built from this guide it stops with “Package php8.4 available, but not installed.” because the php8.4 metapackage was never installed. The 'php8.4*' glob works with that dated release as well.
Patching the running servers isn’t the end of it. Instances launched later from an old AMI or launch template boot on the old release and come up vulnerable again, so rebuild your AMI or point the launch template at a current one.
Workers that are already running keep the old code in memory until they restart. The package scripts restarted php-fpm and httpd on their own in one of our runs, but restart both anyway so you know it happened (drop httpd if Nginx serves your PHP, as in the WordPress with Nginx setup):
sudo systemctl restart php-fpm httpdLong-running PHP CLI processes such as queue workers under supervisor also need a restart, because they loaded PHP when they started and php-fpm restarts don’t touch them. The package version says nothing about a process that was already running, so confirm both services started after the upgrade:
systemctl show -p ActiveEnterTimestamp php-fpm httpdBoth timestamps must be later than the upgrade, otherwise old workers are still answering requests. This output and the two blocks after it come from the existing server where we ran the PHP-only upgrade.
ActiveEnterTimestamp=Thu 2026-10-22 20:02:17 UTC
ActiveEnterTimestamp=Thu 2026-10-22 20:02:18 UTCTo find the upgrade time, read the dnf history. The upgrade is the newest transaction.
sudo dnf history list | head -4Here the upgrade ran at 20:01 and both services entered the active state at 20:02:17 and 20:02:18, so the restarts came after it. If a timestamp predates the upgrade, run the restart again and recheck.
ID | Command line | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
4 | upgrade --releasever=lat | 2026-10-22 20:01 | Upgrade | 18
3 | -y -q install php8.4-bcm | 2026-10-22 20:01 | Install | 193 Finally, ask the web server rather than the CLI, since the CLI binary can be patched while a pool still runs old code. This is the check that proves what readers of your site actually hit. Drop a small probe page into your web root and request it. Set WEB_ROOT to your site’s document root if it isn’t Apache’s default (an Nginx site usually has its own):
WEB_ROOT=/var/www/html
echo '<?php echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;' | sudo tee "${WEB_ROOT}/probe.php" > /dev/null
curl -s http://localhost/probe.phpThe page answers through PHP-FPM with the fixed version. Before the upgrade the same page printed 8.4.25 fpm-fcgi, so if you still see an older number here, a pool is running old code and needs another restart:
8.4.27 fpm-fcgiDelete the probe once you’ve read it, because it tells anyone who requests it your exact PHP version.
sudo rm "${WEB_ROOT}/probe.php"PHP 8.5, 8.3 and 8.2 on AL2023 also have fixed builds in the latest release (8.5.12, 8.3.36 and 8.2.35). The AL2023 php8.1 packages did not: on 22 October 2026 the newest one was 8.1.34-1.amzn2023.0.1 from December 2025, so move any PHP 8.1 site to 8.4 instead of waiting on it.
Test PHP with Apache httpd
Install Apache httpd to test PHP scripts execution. On AL2023 Apache runs the event MPM and hands .php requests to PHP-FPM through /etc/httpd/conf.d/php.conf, which is why the install line above leaves out php8.4-modphp. Add that package only if you switch Apache to the prefork MPM. That’s the setup we’d keep, because Apache never loads PHP into its own workers and PHP runs under a separate php-fpm service you can restart on its own.
sudo dnf -y install httpdThe httpd unit pulls php-fpm in when it starts (a Wants=php-fpm.service drop-in), but php-fpm itself is installed disabled. Enable both services explicitly so PHP comes up even if you later stop Apache or put Nginx in front:
sudo systemctl enable --now php-fpm httpdCreate a PHP info script inside the default Apache web root.
echo '<?php phpinfo(); ?>' | sudo tee /var/www/html/phpinfo.php > /dev/nullOpen your web browser and input http://SERVER_IP/phpinfo.php. On EC2 the instance’s security group must allow inbound TCP 80 from your address, because nothing reaches Apache otherwise. On our test server the page headed itself “PHP Version 8.4.27” and listed FPM/FastCGI as the Server API, which confirms Apache is handing requests to php-fpm and not to mod_php.
The phpinfo page tells anyone who finds it your exact PHP build, paths and loaded modules, so remove it once you’ve checked it:
sudo rm /var/www/html/phpinfo.phpCheck the available extensions.
php --modulesThe list matches the packages installed earlier, plus the extensions built into php8.4-common:
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
exif
FFI
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
ldap
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_pgsql
pdo_sqlite
pgsql
Phar
random
readline
Reflection
session
SimpleXML
sockets
SPL
sqlite3
standard
tidy
tokenizer
xml
xmlreader
xmlwriter
xsl
zip
zlib
[Zend Modules]With mysqlnd and pgsql loaded, PHP is ready to talk to a database such as MySQL 8.4 on the same host. Refer to the official PHP 8.4 release page for more reading.
Other articles on Amazon Linux:
1 thought on “How To Install PHP 8.4 on Amazon Linux 2023”