diff --git a/.github/workflows/docker.yml b/.github/workflows/docker.yml
index 4ecc6ccee..d6bbb3150 100644
--- a/.github/workflows/docker.yml
+++ b/.github/workflows/docker.yml
@@ -6,7 +6,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        images: [ubuntu18.04, ubuntu20.04, ubuntu22.04, debian11, archlinux]
+        images: [ubuntu20.04, ubuntu22.04, debian11, archlinux]
 
     runs-on: ubuntu-latest
     timeout-minutes: 30
diff --git a/README.md b/README.md
index 22e5e0390..4839bbcaa 100644
--- a/README.md
+++ b/README.md
@@ -39,7 +39,7 @@ cd pwndbg
 ./setup.sh
 ```
 
-Pwndbg is supported on Ubuntu 18.04, 20.04, and 22.04 with GDB 8.1 and later. We do not test on any older versions of Ubuntu, so `pwndbg` may not work on these versions. We may accept pull requests fixing issues in older versions on a case by case basis, please discuss this with us on [Discord](https://discord.gg/x47DssnGwm) first. You can also always checkout an older version of `pwndbg` from around the time the Ubuntu version you're interested in was still supported by Canonical, or you can attempt to build a newer version of GDB from source.
+Pwndbg is supported on Ubuntu 20.04, and 22.04 with GDB 9.2 and later. We do not test on any older versions of Ubuntu, so `pwndbg` may not work on these versions (for Ubuntu 18.04 use the [2023.07.17: ubuntu18.04-final release](https://github.com/pwndbg/pwndbg/releases/tag/2023.07.17)). We may accept pull requests fixing issues in older versions on a case by case basis, please discuss this with us on [Discord](https://discord.gg/x47DssnGwm) first. You can also always checkout an older version of `pwndbg` from around the time the Ubuntu version you're interested in was still supported by Canonical, or you can attempt to build a newer version of GDB from source.
 
 Other Linux distributions are also supported via `setup.sh`, including:
 
diff --git a/docker-compose.yml b/docker-compose.yml
index c3d4ccdf7..ad6a7fbab 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -12,14 +12,6 @@ services:
     volumes:
       - .:/pwndbg
 
-  ubuntu18.04:
-    <<: *base-spec
-    build:
-      context: .
-      dockerfile: Dockerfile
-      args:
-        image: ubuntu:18.04
-
   ubuntu20.04:
     <<: *base-spec
     build:
diff --git a/docs/index.md b/docs/index.md
index 7dbf4a51b..c810a6cbf 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -27,7 +27,7 @@ Pwndbg exists not only to replace all of its predecessors, but also to have a cl
 
 ## How?
 
-Installation is straightforward.  Pwndbg is best supported on Ubuntu 14.04 with GDB 7.7, and Ubuntu 16.04 with GDB 7.11.  
+Installation is straightforward. Pwndbg is best supported on Ubuntu 20.04 or 22.04 and GDB >= 9.2.
 
 ```shell
 git clone https://github.com/pwndbg/pwndbg
diff --git a/tests/gdb-tests/tests.sh b/tests/gdb-tests/tests.sh
index dc30c51e8..93e8258f7 100755
--- a/tests/gdb-tests/tests.sh
+++ b/tests/gdb-tests/tests.sh
@@ -10,7 +10,7 @@ set -o pipefail
 mkdir -p ~/.parallel
 . $(which env_parallel.bash)
 
-# Workaround for Ubuntu 20.04/18.04 CI. If no aliases are defined
+# Workaround for Ubuntu 20.04 CI. If no aliases are defined
 # `env_parallel --record-env` will have non-zero exit code for older versions of
 # `parallel`, so we define a dummy alias here
 alias __dummy=foo
diff --git a/tests/gdb-tests/tests/test_command_vmmap.py b/tests/gdb-tests/tests/test_command_vmmap.py
index 136885333..58e9a701d 100644
--- a/tests/gdb-tests/tests/test_command_vmmap.py
+++ b/tests/gdb-tests/tests/test_command_vmmap.py
@@ -124,7 +124,7 @@ def test_command_vmmap_on_coredump_on_crash_simple_binary(start_binary, unload_f
     def assert_maps():
         for vmmap, expected_map in zip(vmmaps, expected_maps):
             # On different Ubuntu versions, we end up with different results
-            # Ubuntu 18.04: vmmap.objfile for binary vmmap has binary file path
+            # Ubuntu 18.04*: vmmap.objfile for binary vmmap has binary file path
             # Ubuntu 22.04: the same vmmap is named as 'loadX'
             # The difference comes from the fact that the `info proc mappings`
             # command returns different results on the two.
@@ -136,6 +136,10 @@ def test_command_vmmap_on_coredump_on_crash_simple_binary(start_binary, unload_f
             # it becomes r-xp and can be readable when we target the coredump
             # Likely, this is because on x86/x64 you can't set memory to be
             # eXecute only, and maybe generate-core-file was able to dump it?
+            #
+            # *NOTE: Ubuntu 18.04 is not supported anymore; leaving this code here
+            # but feel free to remove it in the future if it is not needed anymore
+            # for future versions
             if vmmap[-1] == expected_map[-1] == "[vsyscall]":
                 assert vmmap[:2] == expected_map[:2]  # start, end
                 assert vmmap[3] == expected_map[3] or vmmap[3] in ("r-xp", "--xp")