ZenTao Project Management 22.7

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick ZenTao Project Management 22.7 on Ubuntu 24.04 as the software version and your Region, then choose Launch through EC2. Choose m5.large (or larger for many users), your key pair and a security group as above.

To launch with the AWS CLI instead, run the following command and 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 \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=zentao}]'

First boot builds the database. It takes about two minutes after the instance is running.

Connect over SSH as the login user for your version:

• ZenTao Project Management 22.7 on Ubuntu 24.04: SSH user is ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

First boot creates the database, the settings file and the administrator password, and it mints the certificate. nginx and Apache start only after it has finished. zentao-egress-guard loads the outbound rules for the zentao user at every boot. Check the services:

systemctl is-active nginx apache2 php8.3-fpm mariadb zentao-egress-guard zentao-firstboot
sudo test -f /var/lib/sac/data/zentao-firstboot.done && echo FIRSTBOOT_DONE

All six units are active, and the first boot marker is present:

active active active active active active FIRSTBOOT_DONE

Only SSH and nginx listen on network ports. Apache listens on the loopback address only, behind nginx. MariaDB has no network listener at all, and PHP-FPM uses a local socket. List the listeners:

sudo ss -lntp | awk 'NR>1 && $4 !~ /^127\.0\.0\.5[34]/ {split($6, p, "\""); print $4, p[2]}' | sort

0.0.0.0:22 sshd 0.0.0.0:443 nginx 0.0.0.0:80 nginx 127.0.0.1:8080 apache2 [::]:22 sshd [::]:443 nginx [::]:80 nginx

Print the credentials file:

sudo cat /root/zentao-credentials.txt

Only root can read the file. It contains the following:

# ZenTao Project Management 22.7 - generated on first boot by zentao-firstboot.service
# These credentials are unique to this instance; none was baked into the image. Keep this file secret. ZENTAO_URL=https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/ ZENTAO_ADMIN_USER=admin ZENTAO_ADMIN_PASSWORD=<ZENTAO_ADMIN_PASSWORD>
#
# Open ZENTAO_URL in a browser (self-signed certificate minted on this instance's first boot; port 80 redirects to # https) and sign in with the account and password above. The installer has already run and is not on this image. # Spreadsheet IMPORT is disabled on this image (vendored phpspreadsheet 1.8.2 XXE, no fixed ZenTao release; see the # guide). Export works. # MariaDB: unix socket only (no TCP listener, no database password: ZenTao runs as the OS user zentao); # sudo mysql zentao (root signs in over the socket) # Change the password:
sudo zentao-set-password
# Change the name it serves as:
sudo zentao-set-hostname <your-dns-name>
# Hosts in this VPC ZenTao may reach (LDAP, SMTP): /etc/sac/zentao-egress-allow.conf
# User guide: https://secureanycloud.com/stacks/zentao-project-management-22-7/

The URL uses the instance's public DNS name from the EC2 instance metadata, and the certificate also names the public and private IP addresses. nginx answers only to the names in the certificate.

The name is fixed at first boot. If you stop and start the instance without an Elastic IP and its public address changes, run sudo zentao-set-hostname with the new name (Step 9). A better fix is to give the instance an Elastic IP or your own DNS name.

To check the sign-in end to end from the instance itself, run the following command. It checks the HTTPS redirect, the refused paths, the refused spreadsheet import, the administrator password through ZenTao's real sign-in, and a refused wrong password:

sudo zentao-cred-roundtrip

OK https 301 + no installer/upgrader/my.php/sources + spreadsheet import 403 + administrator sign-in + wrong password refused

Open the ZENTAO_URL in your browser. The certificate is self-signed, so your browser asks you to confirm it the first time. You can install your own certificate instead (Step 9). Sign in with the account admin and the password from Step 4.

The first time you sign in, ZenTao may show a short tour. Close it with Got it. A new ZenTao has no products or projects yet, so the dashboard shows zero counts, the guides for each role and your own recent activity.

Make the account yours. Open the avatar menu (top right), choose Profile, then Edit Profile to set your name and email address. Password resets and notifications go to that address. Choose Change Password to set your own password. Then delete ZENTAO_ADMIN_PASSWORD from /root/zentao-credentials.txt so the file does not hold an old password.

If you lose the administrator password, set a new one from the instance. Without an option, the command generates a random password and writes it to the credentials file. With --stdin, it reads the password you type (12 to 72 letters and digits). Either way, it clears the account's lockout and signs every session out:

sudo zentao-set-password
sudo zentao-set-password --stdin

ZenTao organises work as products (what you build: stories, plans, releases and bugs) and projects (how you build it: sprints or stages, tasks, team and effort).

Choose Product, then Create Product to name a product and its owner.

Choose Project, then Create Project to start a project in the model you choose (Scrum, Waterfall or another). Link it to products and set the manager and dates.

The Admin menu holds the system settings, feature options, users and permissions, notifications and add-ons. Its right-hand column and the Popular Add-ons row show news, patches and paid editions fetched from zentao.net (Step 7).

Choose Admin, Users, then Add User to create an account for each person. Give each account a department, a role and a permission group that decides what the person can see and change.

Email. Mail is off until you configure it. Open Admin, Notifications, Email, choose SMTP and enter your server, port, encryption and account. Then send the test message. Amazon SES works. Use its SMTP endpoint for your Region, port 587 with TLS and an SES SMTP user.

Outbound connections from ZenTao. The zentao user (PHP-FPM) can reach public internet addresses, such as Amazon SES, a public SMTP relay or a webhook service. It cannot reach the instance metadata service, loopback services, IPv6 or any address inside your VPC.

To let ZenTao reach a private host, such as an SMTP relay or LDAP server in your VPC, add one IPv4 address or CIDR per line to the allow list. Then reload the rules and restart PHP-FPM:

echo '<private-ip>' | sudo tee -a /etc/sac/zentao-egress-allow.conf
sudo systemctl restart zentao-egress-guard php8.3-fpm

Metadata, link-local, loopback and multicast addresses are never allowed. An entry for one of them stops the rules and PHP-FPM from starting until you remove it, so a mistake fails closed. To see the rules in force, run sudo nft list table inet sac_zentao_egress.

ZenTao's own internet requests. The dashboard's Zentao Dynamic panel and the admin pages show news and add-ons from zentao.net. The server fetches the list from api.zentao.net, and your browser loads the pictures from static.zentao.net. No project data is sent. If the instance has no route to the internet, the panels stay empty.

Spreadsheet import is disabled. ZenTao 22.7 bundles PhpSpreadsheet 1.8.2 to read uploaded Excel files. That version's XLSX reader has published XML external entity (XXE) flaws (GHSA-6hwr-6v2f-3m88, GHSA-7cc9-j4mv-vcjp, GHSA-jw4x-v69f-hh5w, GHSA-ghg6-32f9-2jp7 and GHSA-3x94-m842-937c). A crafted spreadsheet could make the server read local files or contact other hosts.

No ZenTao release ships a fixed version, so SecureAnyCloud refuses the import itself, twice. Apache answers 403 to any request for ZenTao's import (in the address, the API, any method, any spelling or encoding), and PHP refuses it again before ZenTao runs.

Everything else works, including Export (CSV, XML and HTML) and creating stories, tasks, bugs and test cases one at a time or with ZenTao's batch create forms. If you try to import, the browser shows this message.

To check the block from the instance, run:

H=$(sudo grep '^ZENTAO_URL=' /root/zentao-credentials.txt | cut -d= -f2- | sed -E 's#https://([^/]+)/#\1#') for p in '/index.php?m=transfer&f=import&module=story' '/index.php?f=Import&m=Transfer' '/transfer-import-story.html' '/api.php/v2/transfers/import'; do curl -sk -o /dev/null -w "%{http_code} $p\n" --resolve "$H:443:127.0.0.1" "https://$H$p" done

403 /index.php?m=transfer&f=import&module=story 403 /index.php?f=Import&m=Transfer 403 /transfer-import-story.html 403 /api.php/v2/transfers/import

The following are not available on this image:

• Code repositories. ZenTao's repository browser (CI&CD, Code) runs git and svn commands. PHP on this image cannot run programs, and svn is not installed, so linking a repository does not work. Track commits by mentioning story, task and bug IDs in your commit messages and linking them by hand, or use your Git host's own integrations.
• Add-ons. Admin, Add-ons asks you to create a file on the server to confirm you are the administrator, then installs plugins by writing into the ZenTao code. The code is read-only to PHP, so plugins cannot be installed. The Upgrade link at the bottom right of every page advertises ZenTao's paid editions, which are not part of this image.
• The scheduler. ZenTao runs its scheduled tasks from the browser while someone is signed in, not from an operating system timer. The tasks (Admin, System, Cron Job) send queued mail and webhooks, delete old logs and update the dashboard figures. Mail and webhooks therefore go out while your team is using ZenTao. There is no crontab on the image.
• AI features. The Agent menu is ZenTao's AI assistant. It needs a language model service that you configure yourself, and it sends the content you ask it about to that service. Nothing is configured on a new instance.

Point a DNS record at the instance (an Elastic IP keeps the address stable), then set the name that ZenTao is served as. The command mints a new self-signed certificate for the name, points nginx at it, updates the URL in /root/zentao-credentials.txt and keeps the name across reboots:

sudo zentao-set-hostname <your-domain>

To use a certificate from a public or private certificate authority instead, for example one issued by Let's Encrypt for <your-domain>, copy it over the generated pair and reload nginx. Running zentao-set-hostname again replaces it with a self-signed one:

sudo install -m 0644 <your-domain>.crt /etc/nginx/ssl/zentao.crt
sudo install -m 0600 <your-domain>.key /etc/nginx/ssl/zentao.key
sudo nginx -t && sudo systemctl reload nginx

Only the application is served. The installer, the upgrader, the settings file, the developer tools, a PHP file under the uploads and the sources answer 403 or 404. Plain HTTP redirects to HTTPS, and a request for a name the instance does not serve is closed without an answer (curl shows 000). Check this:

H=$(sudo grep '^ZENTAO_URL=' /root/zentao-credentials.txt | cut -d= -f2- | sed -E 's#https://([^/]+)/#\1#') for p in / '/index.php?m=user&f=login' /install.php /upgrade.php /config/my.php /dev.php /checktable.php /data/x.php /.htaccess /README.md; do curl -sk -o /dev/null -w "%{http_code} $p\n" --resolve "$H:443:127.0.0.1" "https://$H$p" done curl -s -o /dev/null -w 'http:// -> %{http_code}\n' --resolve "$H:80:127.0.0.1" "http://$H/" curl -sk -o /dev/null -w 'unknown host name -> %{http_code}\n' --resolve "other.example:443:127.0.0.1" "https://other.example/" || true

302 / 200 /index.php?m=user&f=login 403 /install.php 403 /upgrade.php 403 /config/my.php 403 /dev.php 403 /checktable.php 403 /data/x.php 403 /.htaccess 403 /README.md http:// -> 301 unknown host name -> 000

Sign-in and request limits. nginx limits requests for each client address. That is the IPv4 address the connection comes from or, for IPv6, the /64 network it comes from, so a client cannot dodge a limit by moving to another address in its own IPv6 network. A header, referrer or cookie that a client sends plays no part. The limits per client address are:

• Every way of signing in: 10 a minute, with a burst of 10. This covers the sign-in form, ZenTao's JSON sign-in, api.php/v1/tokens, api.php/v2/users/login, the other addresses and spellings ZenTao accepts a sign-in on, and any request that carries an Authorization header.
• Every request that sends data: 60 a minute, with a burst of 40. This covers any method other than GET or HEAD, and any request with a body.
• All requests: 1800 a minute, with a burst of 600.

Over a limit, nginx answers 429 Too Many Requests and ZenTao never sees the request. A person working in ZenTao stays well inside the limits.

ZenTao's own lockout still applies to the sign-in form (6 wrong passwords lock the account for 10 minutes). ZenTao 22.7's JSON sign-in does not count failures toward it, which is why nginx limits every sign-in path. The nginx limit counts requests per client address, not per account. Requests for one account from many different addresses are each allowed their own 10 a minute on the JSON sign-in, so give every account a long password.

Two kinds of request are refused outright. One is a GET or HEAD request with a body (400). The other is a zp "keep me logged in" cookie that is not the 40-character value ZenTao itself sets (403), because ZenTao tries that cookie as a password on any page.

You can watch the limit from the instance. The following command sends twelve wrong JSON sign-ins in a row. nginx passes the first eleven to ZenTao and refuses the rest. The requests come from 127.0.0.2, a loopback address of their own, so the limit they reach does not affect anything else:

H=$(sudo grep '^ZENTAO_URL=' /root/zentao-credentials.txt | cut -d= -f2- | sed -E 's#https://([^/]+)/#\1#') for i in $(seq 1 12); do curl -sk -o /dev/null -w '%{http_code} ' --interface 127.0.0.2 --resolve "$H:443:127.0.0.1" -H 'X-Requested-With: XMLHttpRequest' \
  --data 'account=nobody&password=wrong' "https://$H/index.php?m=user&f=login&t=json" done; echo

200 200 200 200 200 200 200 200 200 200 200 429

If your users reach ZenTao through a load balancer or another proxy, every request arrives from the proxy's address and shares one set of limits. Scripts that call the API from one host share a set of limits too. To change a limit, edit the rate= and burst= values in /etc/nginx/conf.d/sac-zentao.conf and /etc/nginx/sites-available/sac-zentao, then check and reload nginx:

sudo nginx -t && sudo systemctl reload nginx

ZenTao's database account has no password. MariaDB accepts it only over the local socket from processes running as zentao, and MariaDB does not listen on the network. Verify this:

sudo mysql -N -B -e "SELECT CONCAT(User, '@', Host, ' authenticates by ', JSON_VALUE(Priv, '$.plugin'), ', password set: ', IF(IFNULL(JSON_VALUE(Priv, '$.authentication_string'), '') = '', 'no', 'yes')) FROM mysql.global_priv WHERE User = 'zentao'; SELECT CONCAT('skip_networking: ', @@skip_networking);"

zentao@localhost authenticates by unix_socket, password set: no skip_networking: ON

The certificate was generated on this instance and names its own addresses. Inspect it:

H=$(sudo grep '^ZENTAO_URL=' /root/zentao-credentials.txt | cut -d= -f2- | sed -E 's#https://([^/]+)/#\1#')
echo | openssl s_client -connect 127.0.0.1:443 -servername "$H" 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

subject=CN = ec2-<public-ip-dashed>.compute-1.amazonaws.com, O = sac X509v3 Subject Alternative Name: DNS:ec2-<public-ip-dashed>.compute-1.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, IP Address:127.0.0.1, DNS:localhost

None of the services can reach the instance metadata service, so a webhook or mail server address pointed at it gets nothing back. Verify this:

systemctl show nginx apache2 php8.3-fpm mariadb zentao-firstboot -p Id -p IPAddressDeny

IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 Id=nginx.service IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 Id=apache2.service IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 Id=php8.3-fpm.service IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 Id=mariadb.service IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 Id=zentao-firstboot.service

Everything you enter is in the MariaDB database zentao (/var/lib/mysql). Attachments, sessions, caches, logs and ZenTao's own backups are under /var/lib/zentao, and the settings file is /etc/zentao/my.php. All three are on the root volume, so the simplest backup is an EBS snapshot of it.

ZenTao also makes its own backups. Choose Admin, System, Backup, Start Backup to save a database dump, the attachments and a copy of the ZenTao code (about 180 MB) to /var/lib/zentao/tmp/backup, which ZenTao shows as /var/www/zentao/tmp/backup. ZenTao keeps the last 14 days. The backups stay on the instance, so copy them off it, to Amazon S3 for example:

sudo ls -l /var/lib/zentao/tmp/backup

To take a database copy of your own while ZenTao is running, run:

sudo mariadb-dump --single-transaction --routines zentao | gzip > <backup-dir>/zentao-$(date +%F).sql.gz
sudo tar -C / -czf <backup-dir>/zentao-files-$(date +%F).tar.gz var/lib/zentao/data etc/zentao

Backups hold every password hash, so store them as carefully as the instance.

To give attachments and the database more room, enlarge the root volume in the EC2 console (Volumes, Modify); Ubuntu grows the file system on the next boot.

The code is read-only to PHP, and the upstream upgrader is not reachable. New ZenTao releases arrive as new versions of this listing, and support can help you move your data to one.

Operating system security updates install automatically. Run sudo apt-get update && sudo apt-get upgrade to apply everything else. nginx, Apache, PHP-FPM and MariaDB restart cleanly, and ZenTao keeps all of its data.

The components are in these locations:

• ZenTao: /var/www/zentao (owned by root, read-only to PHP; Apache serves www/)
• Settings: /etc/zentao/my.php (root, readable by the zentao group)
• Database: MariaDB database zentao (/var/lib/mysql)
• Attachments, sessions, caches, logs and backups: /var/lib/zentao
• nginx (HTTPS, host names, limits): /etc/nginx/sites-available/sac-zentao and /etc/nginx/conf.d/sac-zentao.conf
• Apache site (127.0.0.1:8080 only): /etc/apache2/sites-available/sac-zentao.conf and /etc/apache2/sac-zentao-import-deny.conf
• Certificate and key: /etc/nginx/ssl/zentao.crt, /etc/nginx/ssl/zentao.key
• PHP-FPM pool: /etc/php/8.3/fpm/pool.d/zentao.conf
• Outbound allow list: /etc/sac/zentao-egress-allow.conf (zentao-egress-guard.service)
• Helpers: /usr/local/sbin/zentao-set-password, zentao-set-hostname, zentao-cred-roundtrip
• Credentials: /root/zentao-credentials.txt (mode 0600)
• Source record: /usr/share/doc/zentao/SOURCE.txt

Known issues in ZenTao 22.7 that no ZenTao release fixes yet. Both need a signed-in account:

• CVE-2026-111346 (medium): a signed-in user can edit another user's comment (action::editComment does not check who wrote it).
• CVE-2026-121514 (medium): a weakness in the check ZenTao makes when a user's permission groups change (userModel::checkGroupChange). It needs a user who may already edit users.

Give accounts only to people you trust with your projects, keep user editing to administrators, and review the Recents history if a comment looks changed. New versions of this listing will carry ZenTao's fixes when they are released.

ZenTao's JSON sign-in and the lockout. ZenTao 22.7 answers a failed JSON sign-in (the form its client apps use) before it counts the failure, so ZenTao's own 6-attempt lockout does not apply to that path.

SecureAnyCloud has not changed ZenTao's code to fix this. Every file from the release is as Easysoft published it, and /usr/share/doc/zentao/SOURCE.txt records the release checksum. The image bounds guessing at nginx instead, at 10 sign-in attempts a minute for each client address (an IPv4 address or an IPv6 /64) on every sign-in path (Step 10). That is a limit per client address, not per account. There is no per-account lockout on the JSON sign-in, so give every account a long password.

Recommendations:

• Allow port 22 from your admin network only, and ports 80 and 443 only from the networks your team works from.
• Use your own DNS name and a certificate that your users' browsers trust (Step 9).
• If your users reach ZenTao through a load balancer or proxy, they share its address and one set of sign-in limits. Review the limits (Step 10).
• Set your own email address on the administrator and change its password (Step 5). Give each person their own account in a permission group with only the access they need.
• Allow only the private hosts ZenTao needs in /etc/sac/zentao-egress-allow.conf (Step 7).
• Copy ZenTao's backups off the instance, keep the operating system patched, and snapshot the root volume regularly.