GLIBC_2.28 Not Found on Amazon Linux 2: Node.js 18+, Python 3.10+ and OpenSSL, Fixed (2026)

"version `GLIBC_2.28' not found (required by node)" on Amazon Linux 2 means the program you are running was built for a newer Linux than the one under it. Amazon Linux 2 ships glibc 2.26, the core C library every program depends on, and it will never get a newer one. Official Node.js builds from version 18 onward need glibc 2.28, and Python 3.10 and later need OpenSSL 1.1.1, while Amazon Linux 2's default OpenSSL is 1.0.2. You cannot fix this by upgrading glibc. The real fix is moving to Amazon Linux 2023, which has glibc 2.34, OpenSSL 3, and packaged Node.js 24 and Python 3.14. And that move is no longer optional: Amazon Linux 2 reached end of support on June 30, 2026 and no longer receives standard security updates. If you need a working Node or Python on Amazon Linux 2 today, while you plan the move, there are tested workarounds below, and the most popular forum answer for Python is itself out of support.

Ethan set up the booking site for Jake's phone repair shop in 2022, on a small EC2 instance running Amazon Linux 2. It has run quietly ever since. This month Jake asked for text reminders the day before each repair appointment, and the library Ethan wanted needed a current Node.js. He installed Node 22 with nvm, typed node --version, and got two lines about GLIBC_2.27 and GLIBC_2.28. The same week, Jake's nephew tried a small Python script on the same server to pull the day's bookings, and it died on its first import with a message about urllib3 and OpenSSL 1.0.2. Two different errors, one cause: the operating system underneath was older than the software on top. This page explains both errors, every way around them that still works in 2026, and the move that ends them for good.

If you have just hit one of these errors on a server that has worked for years, you have not broken anything. The server is doing exactly what it was built to do, and the world moved on around it. The fixes below are calm, ordered, and none of them needs you to understand C libraries in depth.

Why Amazon Linux 2 can't run new Node.js and Python

Almost every program on Linux leans on a shared library called glibc, the GNU C Library. It handles the basics: opening files, allocating memory, talking to the network. When a program is compiled, it records the oldest glibc version it is willing to work with. If the system's glibc is older than that, the program refuses to start, and you get "version GLIBC_2.28 not found".

Amazon Linux 2 was built around a fixed set of core components, and AWS promised to keep them compatible for the life of the release. That promise is exactly why its glibc never moved. AWS lists the core components as:

Search for glibc 2.27 on Amazon Linux 2 and you will find a forum thread from 2021, read more than 67,000 times, where a customer asked for exactly that. The answer pointed to the same promise: core packages such as glibc keep their compatibility for the life of the release, so a move away from glibc 2.26 was unlikely, and newer toolchains belong to the next Amazon Linux. That next release became Amazon Linux 2023.

Why not just upgrade glibc yourself? Because everything on the system is linked against it, including yum, bash and sshd. Replacing it by hand is one of the few changes that can leave a Linux server unable to run any command at all, including the ones you would use to undo it. Every workaround on this page leaves the system's glibc alone.

The exact errors, decoded

These are the messages people paste into search engines, exactly as they appear on Amazon Linux 2:

Check what you are running in ten seconds:

cat /etc/os-release | head -3      # VERSION="2" means Amazon Linux 2
ldd --version | head -1            # ldd (GNU libc) 2.26
openssl version                    # OpenSSL 1.0.2k-fips
python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"

To see exactly which glibc versions a program wants, ask the program. This lists every glibc version the Node.js binary was built against; the highest number is the one your system must have:

objdump -T $(command -v node) | grep -o 'GLIBC_[0-9.]*' | sort -uV | tail -3
rpm -q glibc                        # the installed package, e.g. glibc-2.26-64.amzn2.0.6

The same family of errors appears with other numbers, "GLIBC_2.25 not found", "GLIBC_2.29 not found", "GLIBC_2.34 not found" and so on, and on other old systems such as CentOS 7 (glibc 2.17) or Ubuntu 18.04 (glibc 2.27). The rule never changes: the number in the message is the minimum the program needs, and the system has less. The text in brackets, such as (required by node), names the file that asked for it, which might be a program, a Python extension module ending in .so, or a plugin.

Which fix to choose

Ethan's rule for clients is simple: use a workaround to get through the week, and book the move for the following one.

The real fix: move to Amazon Linux 2023

AWS's own guidance since June 30, 2026 is direct: Amazon Linux 2 no longer receives standard security updates, remaining on it carries growing risk as new vulnerabilities go unpatched, and customers should move to Amazon Linux 2023 now rather than wait for a later release. Amazon Linux 2023 is supported until June 2029.

Existing Amazon Linux 2 instances do not switch off. In early October 2026, AL2's package repositories still answered yum install for the packages used on this page. What stopped is the stream of standard security updates, so every month on AL2 adds vulnerabilities that will not be patched. That is the real deadline, and it has already passed.

What is Amazon Linux 2023 based on? It is RPM-based and, in AWS's description, built from components of several Fedora versions and other distributions such as CentOS Stream 9, with a kernel taken from kernel.org's long-term-support releases. It is not a copy of any one of them, so packages from Fedora or RHEL repositories are not guaranteed to install. AL2023 releases come every quarter, and each AMI is pinned to its release; in early October 2026 the current one was 2023.12.20260930.

On a fresh Amazon Linux 2023 instance, both of this page's problems disappear in one command each. These ran on Amazon Linux 2023.12, the September 30, 2026 release:

# Node.js 24 (also nodejs20, nodejs22, and nodejs for 18)
sudo dnf install -y nodejs24 nodejs24-npm
node --version          # v24.21.0

# Python 3.13 (also python3.11, python3.12, python3.14)
sudo dnf install -y python3.13 python3.13-pip
python3.13 -c "import ssl; print(ssl.OPENSSL_VERSION)"   # OpenSSL 3.5.8

Two details are worth knowing. The Node packages install versioned commands such as node-24 and npm-24, and the system's alternatives tool points plain node at the one you installed; check it with alternatives --display node. And plain python3 stays at 3.9, because the system's own tools use it; call python3.13 by name, or create a virtual environment with it, rather than changing what python3 points to.

How the move works. There is no command that turns an Amazon Linux 2 instance into Amazon Linux 2023; the two releases are built differently, from the package manager up. For a small server the practical path is a new instance:

1. Launch an Amazon Linux 2023 instance next to the old one, same VPC, subnet, security group and IAM role.
2. Install your runtime with dnf, as above, and copy or redeploy the application.
3. Recreate scheduled jobs, services and log settings, keeping in mind the changed defaults below.
4. Test with real traffic, for example by pointing a test hostname at it.
5. Move the Elastic IP address or DNS record, keep the old instance stopped for a week, then retire it.

Defaults that changed, from AWS's comparison of the two releases, and the ones that catch people on moving day:

• dnf replaces yum, and amazon-linux-extras is gone; runtimes are ordinary packages.
• cron is not installed. AL2023 leaves out the cronie package and recommends systemd timers. sudo dnf install -y cronie brings classic crontab back if you need it today.
• EPEL is not an option. The EPEL 7 repository that AL2's epel extra enabled has not been maintained since June 30, 2024, and AL2023 does not use EPEL.
• /tmp lives in memory (tmpfs), limited to half of RAM. A job that writes large files to /tmp can fail on a small instance; point it at /var/tmp instead.
• Logs go to the systemd journal instead of rsyslog; read them with journalctl.
• Updates are locked to a release. Each AL2023 AMI is pinned to a repository version by default, so a new instance installs the same package versions every time until you choose to move it forward.
• Python 2.7 is gone, and the AWS CLI is version 2.
• SSH defaults changed, so an old client or key type that worked on AL2 can be refused; our SSH permission denied guide covers the usual causes.

Ethan moved Jake's booking site on a Sunday afternoon: new instance, dnf install nodejs24, the app copied over, one systemd timer to replace the reminder cron job, and the Elastic IP moved across. Jake noticed nothing except that the reminders started working.

Turning a cron job into a systemd timer. Jake's reminder job ran from cron at 6 p.m. every day. On Amazon Linux 2023 it became two small files. The service says what to run:

# /etc/systemd/system/send-reminders.service
[Unit]
Description=Send next-day repair reminders

[Service]
Type=oneshot
User=ec2-user
WorkingDirectory=/opt/booking
ExecStart=/usr/bin/node /opt/booking/send-reminders.js

The timer says when:

# /etc/systemd/system/send-reminders.timer
[Unit]
Description=Run send-reminders daily at 18:00

[Timer]
OnCalendar=*-*-* 18:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now send-reminders.timer
systemctl list-timers send-reminders.timer      # shows the next run
journalctl -u send-reminders.service            # shows what the last run printed

Persistent=true is the quiet improvement over cron: if the server was off at 6 p.m., the job runs as soon as it starts again instead of being skipped. The output also lands in the journal automatically, which is where you will look first when a customer says they did not get a reminder. Times follow the server's time zone, so check it with timedatectl.

Before you switch off the old server, make a short list of what is on it, so nothing is forgotten on the new one:

sudo crontab -l; crontab -l; ls /etc/cron.d /etc/cron.daily   # scheduled jobs
systemctl list-unit-files --state=enabled --type=service        # services that start at boot
yum history list | head -20                                      # what was installed by hand
sudo ss -tlnp                                                    # what listens on which port

Node.js 18, 20, 22 or 24 on Amazon Linux 2, if you must stay a little longer

First, what does not work. Every official Node.js build from version 18 onward fails on Amazon Linux 2, whether it comes from nodejs.org, a tarball or nvm install, because nvm downloads those same official builds. In our tests, Node 18.20.8, 22.23.3 and 24.21.0 all stopped at the GLIBC errors above. Older Node 16 still runs, but it reached end of life in 2023 and gets no security fixes.

Option 1: the unofficial glibc-217 builds. The Node.js project runs a separate site, unofficial-builds.nodejs.org, that compiles Node for platforms the main release does not cover. One of those flavors, linux-x64-glibc-217, targets older C libraries, and it exists for Node 20, 22 and 24. Node 20 reached end of life in April 2026, so if you are choosing a version now, choose 22 or 24. On a clean Amazon Linux 2 system, the 22.23.3 and 24.21.0 builds started normally, npm worked, and HTTPS requests succeeded, because Node carries its own OpenSSL. Install it under /usr/local:

V=v24.21.0
cd /tmp
curl -fLO https://unofficial-builds.nodejs.org/download/release/$V/node-$V-linux-x64-glibc-217.tar.xz
sudo mkdir -p /usr/local/lib/nodejs
sudo tar -xJf node-$V-linux-x64-glibc-217.tar.xz -C /usr/local/lib/nodejs
echo 'export PATH=/usr/local/lib/nodejs/node-'$V'-linux-x64-glibc-217/bin:$PATH' | sudo tee /etc/profile.d/nodejs.sh
source /etc/profile.d/nodejs.sh
node --version     # v24.21.0
npm --version

Be clear-eyed about what this is. These builds are produced by the Node.js project's volunteers but are not official releases, there is no ARM64 flavor, so Graviton instances cannot use them, and new releases can appear a day or so after the official ones. Packages that ship their own compiled code can still hit the same GLIBC error even when Node itself runs, because their prebuilt binaries target newer systems; npm then tries to compile them with AL2's GCC 7.3, which may or may not succeed. Treat this as a bridge, not a home.

On Graviton (ARM64) instances, with no glibc-217 flavor to fall back on, the choice is simpler: run Node in a container, or move to Amazon Linux 2023, where dnf install nodejs24 works the same on ARM64 as on x86_64.

Option 2: run Node in a container. A container brings its own libraries, including its own glibc, so the host's age stops mattering. Docker is available on Amazon Linux 2 through extras:

sudo amazon-linux-extras install -y docker
sudo systemctl enable --now docker
sudo docker run --rm node:24 node --version

This works for the app, but the host underneath, its kernel, its SSH server and everything else, is still an Amazon Linux 2 system without security updates. It buys time; it does not buy safety.

Ethan used Option 1 for exactly nine days on Jake's server, long enough to test the reminder feature while he prepared the new instance.

Python 3.10 and later on Amazon Linux 2

Amazon Linux 2's python3 package is Python 3.7, which reached end of life upstream in 2023. Newer Python versions need OpenSSL 1.1.1 or later, and AL2's default OpenSSL is 1.0.2k. There are a few ways forward on AL2, and the best-known one has quietly expired.

The popular answer that has aged out. The most-upvoted reply on a widely read forum thread about Python 3.10 on Amazon Linux 2, viewed more than 32,000 times, recommends sudo amazon-linux-extras install python3.8. It still installs Python 3.8.20, but the topic no longer appears in amazon-linux-extras list, and installing it prints "Extra topic has reached end of support". The extras system reports an end-of-support date of October 14, 2024 for it, and Python 3.8 itself is out of upstream support. It is a dead end, just a quiet one.

Option 1: a standalone Python with uv (the easiest that works). uv, the Python package and version manager from Astral, can download ready-made Python builds that carry their own OpenSSL and SQLite instead of using the system's. On a clean Amazon Linux 2 system, it installed and ran Python 3.13 in under a minute, without root and without touching the system Python:

curl -LsSf https://astral.sh/uv/install.sh | sh
source $HOME/.local/bin/env
uv python install 3.13        # or 3.9, 3.10, 3.11, 3.12, 3.14
uv venv -p 3.13 ~/venvs/app
source ~/venvs/app/bin/activate
uv pip install requests boto3
python -c "import ssl, sqlite3; print(ssl.OPENSSL_VERSION, sqlite3.sqlite_version)"
# OpenSSL 3.5.9 29 Sep 2026  3.53.1

In that environment, urllib3 2.8.0 installed and an HTTPS request to aws.amazon.com returned 200: no urllib3 error, no missing sqlite3, no compiler. It installs per user, under ~/.local, so run the same steps as the user your application runs as, or point a systemd service at the virtual environment's python. Before you pipe any install script into a shell, read it first; that is good practice on any server.

The catch that shows up next: numpy and pandas. A new Python does not change the system's glibc, and packages with compiled code care about glibc too. Python packages ship prebuilt "wheels" labeled with the oldest glibc they support, such as manylinux_2_17 or manylinux_2_28. In October 2026, the newest numpy, 2.5.3, published x86_64 Linux wheels only for glibc 2.27 and later, one step above Amazon Linux 2's 2.26. So on AL2, even with uv's Python 3.13, uv pip install numpy found no wheel it could use, tried to compile numpy from source, and stopped because no C compiler was installed. pandas 3.0.6 failed the same way, because it needs that numpy. requests and boto3 installed normally, and packages such as cryptography still publish wheels for older glibc as well as newer.

You can work around it by asking for an older numpy that still has wheels for your glibc, or by installing gcc and letting it compile, which takes a while and needs more build tools. Both are more signs of the same thing: on Amazon Linux 2, each month a few more packages stop installing cleanly. Amazon Linux 2023's glibc 2.34 takes the newest wheels without a second thought.

And the operating system under this shiny new Python is still Amazon Linux 2, without security updates. For a bridge of a few weeks, though, uv gives you the cleanest Python you can get on AL2.

Option 2: build Python from source against openssl11. AL2 has an openssl11 package with OpenSSL 1.1.1, which is enough for current Python. The detail most guides get wrong: openssl11-devel installs its headers in the normal /usr/include/openssl location and replaces the 1.0.2 development headers, so Python's build finds it with no extra flags. The common advice to feed it pkg-config openssl11 fails on AL2, because that package's pkg-config file refers to names that do not exist. This sequence built Python 3.14.8 on a clean Amazon Linux 2 system:

sudo yum install -y gcc make tar gzip openssl11 openssl11-devel \
  bzip2-devel libffi-devel zlib-devel xz-devel sqlite-devel readline-devel
cd /tmp
curl -fO https://www.python.org/ftp/python/3.14.8/Python-3.14.8.tgz
tar xzf Python-3.14.8.tgz && cd Python-3.14.8
./configure --prefix=/usr/local
make -j"$(nproc)"
sudo make altinstall          # altinstall: never replace the system python3
python3.14 -c "import ssl; print(ssl.OPENSSL_VERSION)"   # OpenSSL 1.1.1zi

Skip openssl11-devel and the same build ends with "Could not build the ssl module! Python requires a OpenSSL 1.1.1 or newer", leaving a Python without ssl or hashlib. With it, pip install requests boto3 worked and HTTPS requests succeeded. Use make altinstall, not make install: it installs python3.14 without touching the system's python3, which other tools on the server expect to be 3.7.

The catch nobody mentions: no sqlite3. Current Python needs SQLite 3.15.2 or later for its sqlite3 module, and Amazon Linux 2's SQLite is 3.7.17. The build finishes and lists _sqlite3 among the modules it could not build, and import sqlite3 then fails with ModuleNotFoundError: No module named '_sqlite3'. If your code, or a library you use, needs SQLite, you would have to build a newer SQLite first, which is one more piece of software you now maintain by hand. On Amazon Linux 2023, python3.13 from dnf has all of it.

Also remember that a hand-built Python gets no security updates from anyone but you. Every Python bugfix release means rebuilding.

"urllib3 v2.0 only supports OpenSSL 1.1.1+": the one-minute unblock

This error appears when a script on Amazon Linux 2's Python 3.7 installs a recent requests or urllib3. urllib3 version 2 refuses to run on OpenSSL older than 1.1.1, and the system Python was built with 1.0.2k. On a clean AL2 system, pip install requests pulled in urllib3 2.0.7 and the import failed with exactly the message in the heading. With the pin below, pip chose urllib3 1.26.20 and the same request returned 200.

To unblock today, keep urllib3 on version 1:

python3 -m pip install --user "urllib3<2"
python3 -c "import requests; print(requests.get('https://aws.amazon.com').status_code)"   # 200

Put the pin in your requirements.txt too, so the next install does not undo it. This is a patch on a patch: Python 3.7 has had no upstream security fixes since 2023, and the operating system under it now has none either. Jake's nephew pinned urllib3 to get his booking script running that evening, and moved it to python3.13 on the new server the following week.

VS Code Remote-SSH, EKS and other places AL2 hits the wall

VS Code Remote-SSH. If you develop on an EC2 instance through Visual Studio Code's Remote-SSH extension, Amazon Linux 2 has already stopped working for you, or soon will. VS Code's documented requirements for the server it installs on the remote machine are a kernel of 4.18 or later, glibc 2.28 or later and libstdc++ 3.4.25 or later, the same line as Node.js, because that server is built on Node. Amazon Linux 2's glibc 2.26 is below it, which is where searches for "vscode glibc 2.28 not found" come from. Two clean ways out: develop against an Amazon Linux 2023 instance, or use a dev container on a supported host. Plain SSH in a terminal keeps working; only the VS Code server is affected.

Amazon EKS. Kubernetes worker nodes hit this wall first. Amazon EKS stopped publishing EKS-optimized Amazon Linux 2 AMIs on November 26, 2025, and Kubernetes 1.33 and later have Amazon Linux 2023 and Bottlerocket node images only. Existing AL2 nodes keep running, but they receive no new Kubernetes versions or AMI updates, and EKS's own FAQ is explicit that EKS extended support for a Kubernetes version does not extend the AL2 node images. If amazon linux 2 end of life eks is what brought you here, the move is to AL2023 or Bottlerocket node groups, tested first on a new node group before draining the old one.

Is there extended support for Amazon Linux 2? As of October 2026, AWS's Amazon Linux 2 FAQ describes no extended-support program to buy: it says AL2 reached end of support on June 30, 2026, no longer receives standard security updates, and that customers should migrate to Amazon Linux 2023 now rather than wait for a later release.

Container images built FROM amazonlinux:2

The container image amazonlinux:2 carries the same glibc 2.26 and OpenSSL 1.0.2k as the AMI, so a Dockerfile built on it hits every error on this page, and its base layer stops receiving security updates along with the operating system. Moving an image is usually smaller work than moving a server, because the changes are all in one file:

Both the amazonlinux:2 and amazonlinux:2023 images are published on Amazon ECR Public, and the Amazon Linux 2023 package commands on this page were run in the 2023 image. If your image only needs Node or Python and nothing Amazon-specific, the official node:24 or python:3.13 images are another sound choice.

The same errors inside AWS Lambda

Lambda runtimes are built on Amazon Linux too, and several still run on Amazon Linux 2. As of October 2026, AWS's runtime table shows:

The GLIBC error in Lambda almost always has the same shape: a package with compiled code, such as a database driver or an image library, was installed on a laptop or build server running a newer Linux, then zipped and deployed to a runtime based on Amazon Linux 2. Two fixes, in order of preference:

1. Move the function to a runtime on Amazon Linux 2023, such as python3.13 or nodejs24.x, and rebuild its dependencies. The python3.10 runtime reaches deprecation on October 31, 2026, so this is due anyway.
2. Build dependencies inside the runtime's own image, so they match its C library. With AWS SAM, sam build --use-container does this for you; otherwise run pip install or npm install inside the matching image from public.ecr.aws/lambda.

Our Lambda "Unable to import module" guide covers the packaging side in detail.

For IT admins: find every Amazon Linux 2 server before it finds you

The hardest part of this migration is usually knowing where Amazon Linux 2 still runs. Three places to look:

• Systems Manager inventory. If your instances are managed nodes, list their operating systems in one call:

  aws ssm describe-instance-information \
    --query "InstanceInformationList[?PlatformName=='Amazon Linux' && PlatformVersion=='2'].[InstanceId,ComputerName]" \
    --output table

  Instances that do not appear at all are not managed; our SSM Agent not online guide fixes that first.
• Launch templates, Auto Scaling groups and AMI pipelines that still reference amzn2-ami images. A template quietly launching new Amazon Linux 2 servers is worse than an old one running.
• Managed platforms built on it: Lambda functions on the runtimes in the table above, Elastic Beanstalk environments on Amazon Linux 2 platforms (see our Elastic Beanstalk guide for its platform retirements), and container images built FROM amazonlinux:2.

Then plan in waves: internet-facing servers first, since unpatched vulnerabilities matter most there, then internal ones, then build and batch systems. For each application, test on Amazon Linux 2023 with the changed defaults in mind, especially cron, EPEL packages and anything that writes large files to /tmp. Where FIPS compliance matters, note that AWS's FAQ lists AL2's FIPS certificates as moving to historical status, while AL2023 offers FIPS certification.

The Amazon Linux 2 glibc checklist

1. Confirm the system: /etc/os-release says version 2, ldd --version says 2.26.
2. Do not try to upgrade glibc.
3. Need Node today? Use the unofficial glibc-217 build or a container, and write down the date you will stop.
4. Need Python today? Pin urllib3<2 for old scripts, or build Python with openssl11-devel and accept no sqlite3.
5. Skip amazon-linux-extras install python3.8; it is out of support.
6. Launch Amazon Linux 2023, dnf install nodejs24 or python3.13, move the app.
7. Replace cron jobs, EPEL packages and /tmp habits.
8. Move Lambda functions to runtimes on Amazon Linux 2023.
9. Find every remaining Amazon Linux 2 instance, template and image.

These errors feel personal when they land, because the server worked yesterday and you changed one thing. But nothing you did caused them. Amazon Linux 2 kept its promise to stay the same for years, and that is exactly what stopped it running today's software. The workarounds on this page will get you through a deadline. The move to Amazon Linux 2023 will get you through the next three years, with security updates and a dnf install for every runtime you need. Jake's booking site now sends its reminders from a server that is supported until 2029, and the only thing Jake noticed was fewer missed appointments.

Revision note. Written October 7, 2026, after Amazon Linux 2's end of support, with every command run on both releases. If an old server has been quietly carrying your business, it has earned a calm, planned retirement, not a panicked one.