Developer Tools AWS

Apache JMeter 5.6.3 on AWS User Guide

| Product: Apache JMeter 5.6.3 on Ubuntu 24.04 on AWS

Overview

This guide covers launching and using the Apache JMeter 5.6.3 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg developer and API tools listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Apache JMeter is the open-source load and performance testing tool from the Apache Software Foundation. You describe a test in a plan (.jmx file): how many virtual users, what they request (HTTP, JDBC, JMS, LDAP, TCP and more) and what counts as a correct answer. JMeter runs the plan, records every sample to a results file (.jtl) and turns it into an HTML dashboard of response times, throughput and errors.

The cloudimg image is a headless load generator, ready from the first boot:

  • Non-GUI test runs and HTML dashboard reports with jmeter -n, the way JMeter recommends running real load tests. Two sample plans are ready in your test-plans folder.
  • A distributed-mode engine that only this instance can drive. jmeter-server listens on the loopback address only (127.0.0.1:1099 and :1100), and its RMI connection uses mutual TLS with a keystore and password generated on your instance's first boot. A client without TLS, or without this instance's keystore and password, is refused, and the RMI ports are not on the network at all.
  • No default secret. The image contains no keystore and no password. First boot generates them and writes them to /var/lib/cloudimg/apache-jmeter-endpoints.notes (root only); the password never appears on a command line or in a log.
  • Test plans cannot read your IAM role credentials. JMeter runs as its own account, jmeter, with no login shell, no sudo and no capabilities, and neither it nor anything it starts can reach the EC2 instance metadata service.
  • Patched libraries. The bundled json-smart and accessors-smart are raised to 2.5.2, which fixes CVE-2024-57699 (a deeply nested JSON response could crash the test run). The Oracle-licensed javadoc assets in docs/ are not shipped; the user manual is online.
  • Results on their own volume. Test plans, results, reports and logs live on a separate 30 GiB data volume mounted at /var/lib/jmeter, which you can resize on its own.
  • Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: the official Apache JMeter 5.6.3 binary release (apache-jmeter-5.6.3.tgz, checked against the SHA-512 digest and GPG signature Apache publishes), Ubuntu's OpenJDK 17 runtime (no JDK), Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent. The build record and JMeter's Apache-2.0 licence and notice are in /usr/share/doc/cloudimg-jmeter/.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

  • An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet.
  • A security group that allows TCP 22 (SSH) from your own networks (for example <your-mgmt-cidr>). Nothing else needs to be open: you work with JMeter over SSH, and jmeter-server is never on the network.
  • Outbound access from the instance to the systems you want to load test.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Apache JMeter 5.6.3 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose an instance type, your key pair, your subnet and the security group above.

m5.large (2 vCPUs, 8 GiB) runs a few hundred light HTTP threads. JMeter is CPU and memory bound, so for heavier tests pick a larger compute-optimised type (for example c6i.2xlarge) and raise the Java heap (Step 7). Launch the load generator in the same Region, and ideally the same VPC, as the system under test, so you measure the system and not the internet in between.

The image has two volumes: a 12 GiB root volume and a 30 GiB data volume (/dev/sdf) for /var/lib/jmeter. Make the data volume bigger at launch if you keep long result files.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --block-device-mappings '[{"DeviceName":"/dev/sdf","Ebs":{"VolumeSize":100,"VolumeType":"gp3"}}]' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=jmeter}]'

Step 2: Connect to your instance

Version SSH user
Apache JMeter 5.6.3 on Ubuntu 24.04 ubuntu 
ssh -i <your-key.pem> ubuntu@<public-ip>

The login message shows how to run a plan and where your keystore details are.

Step 3: Check the services

First boot takes a few seconds: it generates the RMI keystore and its password, creates your folders on the data volume and copies the sample plans, and only then starts jmeter-server. Check that everything is running:

systemctl is-active apache-jmeter-firstboot jmeter-egress-guard jmeter-server \
  && sudo test -f /var/lib/cloudimg/apache-jmeter-firstboot.done && echo FIRSTBOOT_DONE

active
active
active
FIRSTBOOT_DONE

Only SSH listens on the network. jmeter-server (a java process) listens on the loopback address only:

sudo ss -Hlntp | awk '$4 !~ /^127\.0\.0\.5[34]/ {print $4, $6}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort -u | tee /dev/stderr \
  | awk '$1 !~ /^(127\.|\[::ffff:127\.)/ {sub(/.*:/, "", $1); print $1}' | sort -un | xargs | grep -qx '22' && echo "network listeners: 22"

0.0.0.0:22 users:(("sshd"),("systemd"))
[::]:22 users:(("sshd"),("systemd"))
[::ffff:127.0.0.1]:1099 users:(("java"))
[::ffff:127.0.0.1]:1100 users:(("java"))
network listeners: 22

Your folders are on the data volume:

findmnt -no FSTYPE,TARGET /var/lib/jmeter | tee /dev/stderr | grep -q '^ext4 ' && sudo ls /var/lib/jmeter/test-plans | tee /dev/stderr | grep -qx sample.jmx

ext4   /var/lib/jmeter
http-sample.jmx
sample.jmx
Folder What goes there
/var/lib/jmeter/test-plans your .jmx plans (two samples to start from)
/var/lib/jmeter/results results files (.jtl)
/var/lib/jmeter/reports HTML dashboard reports
/var/lib/jmeter/logs jmeter.log files of your runs and jmeter-server.log

Step 4: Your keystore details

/var/lib/cloudimg/apache-jmeter-endpoints.notes (root only) holds the details of this instance's distributed-mode engine, all generated on first boot:

sudo sed -n 's/^\(JMETER_[A-Z0-9_]*\)=.*/\1/p' /var/lib/cloudimg/apache-jmeter-endpoints.notes | tee /dev/stderr \
  | grep -qx JMETER_RMI_KEYSTORE_PASSWORD && echo "notes present"

JMETER_HOME
JMETER_DATA
JMETER_RMI_REGISTRY
JMETER_RMI_SERVER_PORT
JMETER_RMI_CLIENT_CALLBACK_PORTS
JMETER_RMI_KEYSTORE
JMETER_RMI_PROPERTIES
JMETER_RMI_KEYSTORE_PASSWORD
JMETER_RMI_CERT_SHA256
JMETER_REMOTE_RUN
notes present

You rarely need the password itself: JMeter reads it from /etc/jmeter/rmi/rmi-password.properties (readable by root and the jmeter account only) when you pass -q /etc/jmeter/rmi/rmi-password.properties. The keystore holds a self-signed certificate for 127.0.0.1 that is both this instance's identity and the only certificate it trusts. Check that jmeter-server presents this instance's certificate:

FP="$(sudo sed -n 's/^JMETER_RMI_CERT_SHA256=//p' /var/lib/cloudimg/apache-jmeter-endpoints.notes)"
openssl s_client -connect 127.0.0.1:1099 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -ext subjectAltName | tee /dev/stderr \
  | grep -qix "sha256 Fingerprint=$FP" && echo "jmeter-server presents this instance's certificate"

sha256 Fingerprint=0C:2C:0C:78:10:2F:2A:CF:B6:F4:53:60:BF:D4:32:79:66:FF:E5:D4:A5:7E:A6:1C:78:46:42:18:71:6F:63:44
X509v3 Subject Alternative Name: 
    IP Address:127.0.0.1, DNS:localhost
jmeter-server presents this instance's certificate

Step 5: Check the JMeter version

Run JMeter as the jmeter account, from /var/lib/jmeter, so that its log and results land in folders it owns:

sudo -u jmeter bash -c 'cd /var/lib/jmeter && jmeter --version -j logs/version.log' 2>/dev/null | tee /dev/stderr \
  | grep -q '5\.6\.3' && echo "Apache JMeter 5.6.3"

    _    ____   _    ____ _   _ _____       _ __  __ _____ _____ _____ ____
   / \  |  _ \ / \  / ___| | | | ____|     | |  \/  | ____|_   _| ____|  _ \
  / _ \ | |_) / _ \| |   | |_| |  _|    _  | | |\/| |  _|   | | |  _| | |_) |
 / ___ \|  __/ ___ \ |___|  _  | |___  | |_| | |  | | |___  | | | |___|  _ <
/_/   \_\_| /_/   \_\____|_| |_|_____|  \___/|_|  |_|_____| |_| |_____|_| \_\ 5.6.3

Copyright (c) 1999-2024 The Apache Software Foundation

Apache JMeter 5.6.3

Always run your tests as jmeter. It is the account the metadata fence (Step 8) applies to, and the only one, besides root, that can read the keystore. Your own ubuntu shell is not fenced.

Step 6: Run your first test and open the report

sample.jmx is a self-contained plan (5 threads, 20 loops each, no network traffic) that shows the whole flow. Run it in non-GUI mode, write the results to a .jtl file and generate the HTML dashboard at the end of the run (-e -o), then count the samples and errors in the results file:

R="first-run-$(date +%H%M%S)"
sudo -u jmeter bash -c "cd /var/lib/jmeter && jmeter -n -t test-plans/sample.jmx -l results/$R.jtl -j logs/$R.log -e -o reports/$R" | grep 'summary =' \
  && sudo awk -F, 'NR>1 {n++; if ($8 != "true") e++} END {printf "%d samples, %d errors\n", n, e}' "/var/lib/jmeter/results/$R.jtl" | tee /dev/stderr | grep -qx '100 samples, 0 errors' \
  && sudo test -s "/var/lib/jmeter/reports/$R/index.html" && echo "HTML report: /var/lib/jmeter/reports/$R/index.html"

summary =    100 in 00:00:04 =   22.3/s Avg:   150 Min:    12 Max:   251 Err:     0 (0.00%)
100 samples, 0 errors
HTML report: /var/lib/jmeter/reports/first-run-063121/index.html

The report folder must not exist yet (JMeter refuses to overwrite one), which is why each run above gets its own name. To read the report, copy it to your machine and open index.html in your browser:

ssh -i <your-key.pem> ubuntu@<public-ip> "sudo tar -C /var/lib/jmeter/reports -czf - first-run-063121" | tar -xzf -
open first-run-063121/index.html    # macOS; use xdg-open on Linux or start on Windows

You can also turn any existing results file into a report later: sudo -u jmeter bash -c 'cd /var/lib/jmeter && jmeter -g results/<run>.jtl -o reports/<run>-report'.

Step 7: Load test your own system

http-sample.jmx sends 2 threads of 5 HTTPS GET / requests to the host you name with -Jtarget_host and checks that each one answers 200:

R="http-$(date +%H%M%S)"
sudo -u jmeter bash -c "cd /var/lib/jmeter && jmeter -n -t test-plans/http-sample.jmx -Jtarget_host=example.com -l results/$R.jtl -j logs/$R.log" | grep 'summary =' \
  && sudo awk -F, 'NR>1 {n++; if ($8 != "true") e++} END {printf "%d samples, %d errors\n", n, e}' "/var/lib/jmeter/results/$R.jtl" | tee /dev/stderr | grep -qx '10 samples, 0 errors'

summary =     10 in 00:00:01 =   13.2/s Avg:    69 Min:     9 Max:   489 Err:     0 (0.00%)
10 samples, 0 errors

Build your own plans with the JMeter GUI on your workstation (download the same version, 5.6.3, from jmeter.apache.org), then copy them to the instance and run them headless here:

scp -i <your-key.pem> my-plan.jmx ubuntu@<public-ip>:/tmp/
ssh -i <your-key.pem> ubuntu@<public-ip> "sudo install -o jmeter -g jmeter -m 0640 /tmp/my-plan.jmx /var/lib/jmeter/test-plans/ && rm /tmp/my-plan.jmx"

Some things to know for real tests:

  • Load-test only systems you own or have permission to test.
  • Java heap. JMeter starts with a 1 GiB heap. For large tests give it more, for example half the instance's memory: sudo -u jmeter bash -c 'cd /var/lib/jmeter && HEAP="-Xms4g -Xmx4g" jmeter -n ...'.
  • Plugins and drivers. Put extra jars (JDBC drivers, plugins) in /opt/jmeter/lib or /opt/jmeter/lib/ext with sudo; they are then available to every run.
  • Several load generators. To spread a test over more instances, run the same plan on each instance, copy the .jtl files to one of them, join them (keep one header line) and build one report with jmeter -g. This needs no network connection between the instances. (JMeter's own controller-and-servers mode needs its RMI ports open between hosts, which this image deliberately does not do; see Step 9.)

Step 8: What a test plan can reach

Test plans can reach the internet and your private networks, but not the EC2 instance metadata service or a few reserved address ranges. Check the metadata block first: the metadata service gets no answer (000) for the jmeter account and still answers for ubuntu (your SSH account), and every JMeter service on the image carries the metadata block:

{ sudo -u jmeter curl -s -m 5 -o /dev/null -w 'jmeter -> metadata: %{http_code}\n' -X PUT http://169.254.169.254/latest/api/token -H 'X-aws-ec2-metadata-token-ttl-seconds: 60'
  curl -s -m 5 -o /dev/null -w 'ubuntu -> metadata: %{http_code}\n' -X PUT http://169.254.169.254/latest/api/token -H 'X-aws-ec2-metadata-token-ttl-seconds: 60'
  for u in apache-jmeter-firstboot jmeter-egress-guard jmeter-server; do systemctl show -p IPAddressDeny --value "$u" | grep -q '169\.254\.0\.0/16' && echo "$u: metadata denied"; done
} | tee /dev/stderr | xargs | grep -qx 'jmeter -> metadata: 000 ubuntu -> metadata: 200 apache-jmeter-firstboot: metadata denied jmeter-egress-guard: metadata denied jmeter-server: metadata denied' && echo "metadata blocked for JMeter"

jmeter -> metadata: 000
ubuntu -> metadata: 200
apache-jmeter-firstboot: metadata denied
jmeter-egress-guard: metadata denied
jmeter-server: metadata denied
metadata blocked for JMeter

Two things enforce this. Each JMeter service has its own network filter (systemd IPAddressDeny), and an nftables rule rejects the metadata addresses (IPv4 and IPv6, all of 169.254.0.0/16 including the container credential endpoint, fe80::/10) for the jmeter account anywhere on the instance, so a test plan, a JSR223 script or a plugin cannot read the instance's IAM role credentials. If a plan needs AWS credentials (for example to sign requests), give it its own, with only the permissions it needs.

The same nftables table also refuses a few reserved IPv4 ranges for the jmeter account, none of which is a real load-test target: 192.0.0.0/24 (IETF protocol assignments), 198.18.0.0/15 (reserved for benchmarking network devices in isolated labs), 240.0.0.0/4 (reserved) and 224.0.0.0/4 (multicast, dropped rather than rejected). Check it: each reserved address is refused at once (000, in well under a second), and the rule counters show the hits:

for a in 198.18.0.1 192.0.0.9 240.0.0.1; do sudo -u jmeter curl -s -m 5 -o /dev/null -w "jmeter -> $a: %{http_code} in %{time_total}s\n" "http://$a/" || true; done | tee /dev/stderr \
  | awk '$4 == "000" && $6 + 0 < 3 {n++} END {exit n != 3}' \
  && sudo nft list chain inet cloudimg_jmeter_egress output | awk '/"cloudimg-backstop"/ {for (i = 1; i < NF; i++) if ($i == "packets") p = $(i + 1)} END {exit !(p > 0)}' \
  && echo "reserved ranges refused for JMeter"

jmeter -> 198.18.0.1: 000 in 0.000412s
jmeter -> 192.0.0.9: 000 in 0.000201s
jmeter -> 240.0.0.1: 000 in 0.000187s
reserved ranges refused for JMeter

IPv6 is left open apart from the metadata address and link-local: JMeter needs no IPv6 egress of its own beyond the targets your plans name, and a blanket IPv6 block would break load tests against IPv6 services.

Why private networks are not fenced. JMeter's job is to send traffic to the systems you choose, and most systems people load test (internal APIs, databases, services behind a load balancer) live on private addresses in their VPC. Blocking private ranges would stop the product doing its main job, so the image fences only the metadata service, link-local addresses and the reserved ranges above, which are never a load-test target. For the same reason the image does not look up your VPC's address range and block it (some cloudimg images do that for services that should never call into your network): reaching your VPC is what a load generator is for, and 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and 100.64.0.0/10 all stay open to the jmeter account. The flip side: a plan runs with the instance's network position, so it can reach whatever the instance's subnet, route tables and the targets' security groups allow. Run plans you trust, and use security groups or network ACLs on your targets (or extra nftables rules for the jmeter account) if a load generator must not reach some of them.

Step 9: Distributed mode on this instance

jmeter-server is JMeter's remote engine: a controller sends it a plan over Java RMI and it runs the plan and streams the samples back. On this image the engine and the controller both run on the instance, as jmeter, over mutual TLS on loopback. The built-in self-test runs a full test through the engine:

sudo jmeter-selftest | tail -n 1 | tee /dev/stderr | grep -q '^JMETER_SELFTEST_OK '

JMETER_SELFTEST_OK distributed run through jmeter-server (RMI over mutual TLS, 127.0.0.1:1099/1100) as jmeter: 100/100 samples

To run your own plan through the engine, add -r (use the remote engine) and -q /etc/jmeter/rmi/rmi-password.properties (this instance's keystore password):

R="remote-$(date +%H%M%S)"
sudo -u jmeter bash -c "cd /var/lib/jmeter && jmeter -n -t test-plans/sample.jmx -r -q /etc/jmeter/rmi/rmi-password.properties -l results/$R.jtl -j logs/$R.log" \
  | grep -E 'Remote engines have been started|summary =' | tee /dev/stderr | grep -q 'started:\[127.0.0.1\]' \
  && sudo awk -F, 'NR>1 {n++; if ($8 != "true") e++} END {printf "%d samples, %d errors\n", n, e}' "/var/lib/jmeter/results/$R.jtl" | tee /dev/stderr | grep -qx '100 samples, 0 errors' && echo "distributed run OK"

Remote engines have been started:[127.0.0.1]
summary =    100 in 00:00:04 =   23.7/s Avg:   135 Min:    13 Max:   261 Err:     0 (0.00%)
100 samples, 0 errors
distributed run OK

What the engine refuses. A client that turns RMI TLS off, and a client that has the keystore file but not its password, cannot configure the engine:

for X in '-Jserver.rmi.ssl.disable=true' ''; do
  OUT="$(sudo -u jmeter bash -c "cd /var/lib/jmeter && jmeter -n -t test-plans/sample.jmx -r $X -l results/refused.jtl -j logs/refused.log" 2>&1)"
  if grep -q 'could not be configured:\[127.0.0.1\]' <<< "$OUT" && ! grep -q 'engines have been started' <<< "$OUT"; then echo "refused: ${X:-no keystore password}"; else echo "ACCEPTED: ${X:-no keystore password}"; fi
done | tee /dev/stderr | grep -c '^refused: ' | grep -qx 2 && echo "RMI without this instance's keystore and password is refused"

refused: -Jserver.rmi.ssl.disable=true
refused: no keystore password
RMI without this instance's keystore and password is refused

And the engine is not on the instance's network address at all:

IP="$(hostname -I | awk '{print $1}')"
for p in 1099 1100; do if timeout 5 bash -c "exec 3<>/dev/tcp/$IP/$p" 2>/dev/null; then echo "$p open"; else echo "$p refused"; fi; done \
  | xargs | tee /dev/stderr | grep -qx '1099 refused 1100 refused' && echo "RMI is not on the network address"

1099 refused 1100 refused
RMI is not on the network address

On top of that, an nftables rule drops packets from the network to ports 1099 to 1103 and to JMeter's UDP shutdown ports (4445 to 4455), and the security group opens only SSH.

Why there is no remote controller. In JMeter's distributed mode the engine connects back to the controller to deliver results, so a controller on your workstation would need its own ports reachable from the instance, and the RMI ports would have to be opened between hosts. That is the setup behind JMeter's history of RMI attacks, so this image keeps the engine and the controller on the instance and you drive both over SSH. The controller's callback ports are chosen by the system on 127.0.0.1 (client.rmi.localport=0): JMeter 5.6.3 cannot use a fixed callback port with RMI over TLS (the run fails with NotSerializableException: org.apache.jmeter.JMeter$ListenToTest), so leave that setting as it is.

Step 10: Rotate the keystore

To replace the keystore, its certificate and its password with new ones (the old ones stop working at once, and jmeter-server restarts on the new keystore):

sudo jmeter-rmi-keystore --rotate
sudo jmeter-selftest

The new password is written only to /etc/jmeter/rmi/rmi-password.properties and the notes file; it never appears on a command line. Read the new certificate fingerprint with sudo grep ^JMETER_RMI_CERT_SHA256= /var/lib/cloudimg/apache-jmeter-endpoints.notes.

Step 11: Back up and restore

Everything you create is on the data volume, /var/lib/jmeter. Take an EBS snapshot of that volume, or copy your plans and results off the instance:

ssh -i <your-key.pem> ubuntu@<public-ip> "sudo tar -C /var/lib/jmeter -czf - test-plans results reports" > jmeter-$(date +%F).tar.gz

To restore into a new instance of this image, unpack the archive into /var/lib/jmeter as jmeter: sudo -u jmeter tar -C /var/lib/jmeter -xzf - < jmeter-<date>.tar.gz. To grow the data volume, modify it in the EC2 console and then run sudo resize2fs "$(findmnt -no SOURCE /var/lib/jmeter)".

Step 12: Security notes and the build record

jmeter-server runs as jmeter, which has no login shell and no sudo. The service has no capabilities and NoNewPrivileges, sees the rest of the system read-only (ProtectSystem=strict, writable only under /var/lib/jmeter), and has private /tmp and /dev. Some sandbox settings are deliberately relaxed because a Java load generator needs them: JIT compilation (no MemoryDenyWriteExecute), any system call, netlink sockets and up to 8192 threads. The keystore files are readable only by root and jmeter:

getent passwd jmeter | cut -d: -f1,6,7 | tee /dev/stderr | grep -qx 'jmeter:/var/lib/jmeter:/usr/sbin/nologin' \
  && sudo -l -U jmeter 2>&1 | grep -q 'not allowed to run sudo' && echo "jmeter: no login shell, no sudo" \
  && sudo stat -c '%n %U:%G %a' /etc/jmeter/rmi/rmi-keystore.p12 /etc/jmeter/rmi/rmi-password.properties /var/lib/cloudimg/apache-jmeter-endpoints.notes \
  | tee /dev/stderr | grep -c ' root:jmeter 640$' | grep -qx 2 && echo "keystore: root and jmeter only"

jmeter:/var/lib/jmeter:/usr/sbin/nologin
jmeter: no login shell, no sudo
/etc/jmeter/rmi/rmi-keystore.p12 root:jmeter 640
/etc/jmeter/rmi/rmi-password.properties root:jmeter 640
/var/lib/cloudimg/apache-jmeter-endpoints.notes root:root 600
keystore: root and jmeter only

The build record shows where JMeter came from and how its libraries were checked:

sed -n '1,8p' /usr/share/doc/cloudimg-jmeter/BUILD-INFO.txt | tee /dev/stderr | grep -q '^jmeter  *Apache JMeter 5\.6\.3 '

jmeter            Apache JMeter 5.6.3 (jmeter.apache.org, 2024-01-07), Apache-2.0; /opt/jmeter
                  apache-jmeter-5.6.3.tgz sha512 5978a1a35edb5a7d428e270564ff49d2b1b257a65e17a759d259a9283fc17093e522fe46f474a043864aea6910683486340706d745fcdf3db1505fd71e689083
                  docs/ and printable_docs/ not shipped (Oracle-licensed javadoc assets, docs/api/legal/LICENSE; the manual is online)
jars              159 jars = the CVE-gated set (listing sha256 565449bb9d8a8ca658cba8060c094b88fd6b4b074247953196bfb3d07419d3da; jars-sha256.txt)
                  json-smart + accessors-smart raised 2.5.0 -> 2.5.2 (CVE-2024-57699), Maven Central, sha256 pinned
tika              1.28.5 as released; CVE-2025-54988 / -66516 (PDF parser XXE) unreachable: no PDFBox ships, so Tika cannot load its PDF parser
java              openjdk version "17.0.20.1" 2026-08-18 (Ubuntu openjdk-17 JRE, noble, security-patched; no JDK ships)
distributed mode  jmeter-server as the nologin account jmeter: registry 127.0.0.1:1099, engine 127.0.0.1:1100, controller

About the libraries JMeter 5.6.3 bundles:

  • json-smart and accessors-smart are raised from 2.5.0 to 2.5.2 (CVE-2024-57699): a deeply nested JSON response now fails the assertion or extractor cleanly instead of crashing the test.
  • Apache Tika 1.28.5 (used when an assertion or extractor reads a response "as document") has advisories in its PDF parser (CVE-2025-54988, CVE-2025-66516). That parser needs Apache PDFBox, which JMeter does not ship, so Tika cannot load it: a PDF response yields no text and nothing it references is fetched. Do not add PDFBox jars to /opt/jmeter/lib.
  • httpcore5 5.2.4 and dnsjava 2.1.9 have advisories with no fix in the versions JMeter 5.6.3 supports. They can only be triggered by the systems you test (a denial of service of your own test run) or by a DNS resolver you configure yourself in a DNS Cache Manager.

Step 13: Keep it up to date

Ubuntu security updates, including the OpenJDK runtime, install automatically. To apply everything now:

sudo apt-get update && sudo apt-get upgrade -y

JMeter itself is installed from the Apache release, not from an apt repository, so apt-get upgrade does not change it. New JMeter releases arrive as new versions of the AWS Marketplace listing: launch the new version and copy your plans across (Step 11).

Support

  • Email: support@cloudimg.co.uk
  • Website: https://www.cloudimg.co.uk

The other versions on this listing are on the developer and API tools guide.