Operations on KnightLi Blog

How to Manage Multiple Devices and Folders in Syncthing: Topology, Naming, and Versioning

Sun, 31 May 2026 12:23:55 +0800

Syncthing Series

Once Syncthing has many devices and many folders, it can quickly become messy if you do not plan ahead. The typical setup is a phone, tablet, laptop, desktop, and NAS all syncing at once, while folders contain photos, work documents, code projects, chat backups, and ebooks. Every device may modify files, every folder may be shared, and eventually it becomes hard to tell where a file came from and where it will sync next.

To keep Syncthing stable, the core is not installing more clients, but building a management model:

Use a star topology.
Standardize folder IDs and paths.
Use introducers for device relationships.
Separate backups from two-way sync by data direction.
Enable versioning on the central node.
Filter temporary files with ignore patterns.

Topology: Avoid Full Mesh, Prefer Star

Syncthing is a P2P architecture, but that does not mean every device should pair with every other device.

If 5 devices are fully connected, you need to maintain 10 device relationships. When you add a new folder, you also need to accept it, set paths, and confirm sharing across multiple devices. The more devices you have, the higher the management cost.

A star topology is usually better.

Choose one always-on, spacious, and stable device as the hub:

NAS
Synology
soft router
mini PC
a computer that stays on 24/7

All other devices pair only with the hub:

Phone ----\
Tablet ----\
Laptop ---- NAS
Desktop ---/

The phone does not directly add the laptop, and the laptop does not directly add the desktop. If the phone needs to sync photos to a computer, it syncs to the NAS first, then the NAS syncs them to the computer.

This has several benefits:

New devices only need to pair with the NAS.
Folder relationships are managed centrally on the NAS.
The NAS can handle version retention consistently.
When edge devices go offline, the NAS still acts as a buffer.

The tradeoff is that the NAS becomes more important. It should run reliably and have its own backup.

Folder ID Matters More Than the Folder Label

In Syncthing, the real identifier for a synchronized folder is the Folder ID, not the label you see in the UI.

The label is just a display name and may differ across devices. The Folder ID is what determines whether folders on different devices belong to the same sync group.

When creating a folder on the first device, specify a clean ID manually.

For example:

notes-main
work-docs
backup-pixel-photos
backup-iphone-photos
media-ebooks
code-projects

Avoid random generated IDs or long-term-unfriendly names such as test, sync, and new-folder.

A simple naming rule is enough:

Two-way sync: notes-main, work-docs
Phone backups: backup-pixel-photos, backup-iphone-photos
Media distribution: media-ebooks, media-music
Code directories: code-projects

Later, when other devices receive a shared folder, the Folder ID tells you immediately what the folder is for.

Keep Hub Paths Organized

On the NAS or central computer, create one dedicated Syncthing root directory.

For example:

/volume1/Syncthing/
├── Phone_Backup/
│   ├── iPhone15_DCIM/
│   └── Pixel7_DCIM/
├── Work/
│   ├── Office_Docs/
│   └── Coding_Projects/
├── Notes/
│   └── Main_Notes/
└── Media/
    └── eBooks/

Do not scatter sync folders across the system. Scattered paths may feel convenient at first, but they become difficult to maintain.

Recommended rules:

Put all Syncthing-managed folders under one root directory.
Separate phone backups, work documents, and media files into clear sections.
Let folder names reflect purpose, not temporary device state.
Do not use system directories or download caches as long-term sync folders.

If Syncthing runs in Docker, also pay attention to the mapping between host paths and container paths.

For example, the host path:

`1`	`/volume1/Syncthing/Phone_Backup/iPhone15_DCIM`

may be mounted inside the container as:

`1`	`/var/syncthing/Phone_Backup/iPhone15_DCIM`

The path entered in the Web UI is the container path, not the host path.

Introducers: Reduce Multi-device Pairing Work

Syncthing’s Introducer feature is well suited to star topologies.

The idea is to make the NAS an introducer. After that, a new device only needs to pair with the NAS. The NAS can introduce known devices and sharing relationships to the new device, reducing repeated scanning and manual adding across devices.

It works well when:

your home has multiple computers and phones;
the NAS is the long-running hub;
you often add new devices;
you want to reduce pairing work.

But do not use it casually.

Recommended practice:

Only set the NAS or main server as an introducer.
Do not set ordinary phones, tablets, or temporary computers as introducers.
After a new device joins, check which devices and folders were added automatically.
Do not bring untrusted devices into the introducer-managed network.

Introducers improve efficiency, but they also expand automatic relationships. They are best for a clear hub-based network, not a messy temporary device environment.

Separate Backups from Two-way Sync

In multi-folder management, one of the most important rules is: do not use Send & Receive for every folder.

Different folders have different data directions.

Phone Photo Backup

Phone side:

`1`	`Send Only`

NAS side:

`1`	`Receive Only`

The phone sends photos and the NAS receives them. Cleaning phone storage or organizing the NAS folder is less likely to affect the other side.

Multi-device Documents and Notes

Computer side:

`1`	`Send & Receive`

NAS side:

`1`	`Send & Receive`

Whether the phone joins this two-way sync depends on whether you truly edit these files on the phone. If the phone only reads them, consider Receive Only.

Media Distribution

NAS side:

`1`	`Send Only`

Other devices:

`1`	`Receive Only`

This is suitable for ebooks, installers, and reference material distributed from a central folder.

Backup Directories

Primary device:

`1`	`Send Only`

Backup machine:

`1`	`Receive Only`

Then combine it with versioning or snapshots on the backup side.

Enable File Versioning on the NAS

The biggest risks in multi-device sync are accidental deletion and accidental overwrite.

For example:

A computer deletes work documents by mistake.
A phone cleanup tool removes an album directory.
Two devices edit the same note at the same time.
A sync rule is misconfigured and an empty directory is synced over.

Because of this, the central node should enable file versioning.

In the NAS Syncthing Web UI:

Open the target folder settings.
Go to file versioning.
Choose a suitable versioning strategy.

A common choice is Staggered File Versioning. It keeps historical versions by time intervals, retaining older versions more sparsely over time.

You can also use simpler strategies:

Trash Can File Versioning: similar to a recycle bin.
Simple File Versioning: keeps a fixed number of versions.
Staggered File Versioning: keeps versions by time stages.

If you are not sure which to choose, a home NAS can start with Trash Can or Staggered.

Versioning is not a full backup, but it is the undo button you want in multi-device sync.

Filter Temporary Files with Ignore Patterns

When syncing code projects, document folders, or chat backups across many devices, temporary files and caches can create noise.

Common problems include:

wasting bandwidth;
generating meaningless conflicts;
creating different cache files on different operating systems;
blocking directory deletion because ignored files remain.

Add rules in the folder’s Ignore Patterns.

Common temporary files:

1
2
3

(?d).DS_Store
(?d)Thumbs.db
(?d)*~

Node / Python / Java projects:

(?d)node_modules/
(?d)__pycache__/
(?d).pytest_cache/
(?d)target/

If a code project is already managed by Git, it is usually not recommended to sync the .git directory with Syncthing. You can ignore it:

`1`	`(?d).git/`

(?d) means that if the whole directory is going to be deleted, Syncthing may delete these locally generated ignored files as well, preventing leftover cache files from blocking the deletion.

Do not make ignore rules too complex at once. Start with obvious caches and temporary files, then adjust slowly according to real conflicts.

Multi-folder Naming Examples

You can use a fixed naming scheme.

Phone photos:

1
2
3

Folder ID: backup-pixel-photos
Label: Pixel Photos
NAS Path: /volume1/Syncthing/Phone_Backup/Pixel7_DCIM

iPhone photos:

1
2
3

Folder ID: backup-iphone-photos
Label: iPhone Photos
NAS Path: /volume1/Syncthing/Phone_Backup/iPhone15_DCIM

Main notes vault:

1
2
3

Folder ID: notes-main
Label: Main Notes
NAS Path: /volume1/Syncthing/Notes/Main_Notes

Work documents:

1
2
3

Folder ID: work-docs
Label: Work Docs
NAS Path: /volume1/Syncthing/Work/Office_Docs

Ebooks:

1
2
3

Folder ID: media-ebooks
Label: eBooks
NAS Path: /volume1/Syncthing/Media/eBooks

As long as IDs, labels, and paths follow rules, multi-device setups are much easier to control.

Recommended Overall Design

If you already run Docker Syncthing on a NAS, you can design it like this:

Use the NAS as the hub.
Set the NAS as the introducer.
Pair all devices only with the NAS.
Put all sync folders under /volume1/Syncthing/.
Use phone Send Only and NAS Receive Only for photo folders.
Use Send & Receive for work documents and notes.
Use NAS Send Only and other devices Receive Only for distribution folders.
Enable versioning for important folders on the NAS.
Configure ignore rules for code and cache directories.
Back up or snapshot the NAS itself.

Once this structure is in place, adding new devices or folders simply means putting them into the existing rules. You do not need to rethink the sync relationships every time.

Summary

Syncthing gives you a lot of freedom, but the more freedom you have, the more you need rules.

For multi-device and multi-folder setups, avoid a fully connected mesh. A steadier approach is to let a NAS or always-on computer act as the hub, then standardize Folder IDs, paths, and versioning. Use folder types to distinguish backups, two-way sync, and distribution folders.

This keeps Syncthing’s P2P capability while bringing day-to-day management back to one central device. Even with many devices and many folders, the sync system will not turn into a tangle.

Deploy Syncthing with Docker: Compose, Ports, and Volume Mapping Pitfalls

Sun, 31 May 2026 12:12:05 +0800

Syncthing Series

Deploying Syncthing in Docker is a good fit for a NAS, a home server, or a VPS. It can act as an always-on sync node for photos, documents, Markdown notes, or download folders.

The important part of a Docker-based Syncthing setup is not merely whether the container starts. The real questions are:

whether the configuration directory is persistent;
whether the data folders you want to sync are mapped into the container;
whether ports and permissions are prepared in advance.

If these details are not handled well, a container update may wipe your configuration, the path you enter in the Web UI may not point to the real host folder, or sync tasks may fail with Permission denied.

Directory Planning

Start by creating a dedicated directory on the server or NAS, for example:

1
2

mkdir -p ~/syncthing
cd ~/syncthing

Put docker-compose.yml in this directory, and keep Syncthing’s configuration in a subdirectory:

1
2
3

syncthing/
├── docker-compose.yml
└── config/

The actual sync data can live in existing host paths, for example:

1
2

/volume1/downloads
/volume1/photos

Keep the configuration directory separate from the data directories. config stores Syncthing’s own configuration, keys, and index database. Folders such as downloads and photos are the actual data you want to sync.

Option 1: Docker Compose

Docker Compose is the recommended approach because updates, restarts, and migrations are easier to understand later.

Create ~/syncthing/docker-compose.yml:

version: "3"

services:
  syncthing:
    image: syncthing/syncthing:latest
    container_name: syncthing
    hostname: my-nas-syncthing
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    volumes:
      - ./config:/var/syncthing/config
      - /volume1/downloads:/var/syncthing/downloads
      - /volume1/photos:/var/syncthing/photos
    ports:
      - 8384:8384
      - 22000:22000/tcp
      - 22000:22000/udp
      - 21027:21027/udp
    restart: unless-stopped

Start it:

`1`	`docker compose up -d`

Check the status:

1
2

docker compose ps
docker logs -f syncthing

Open the Web UI:

`1`	`http://server-ip:8384`

After the first login, set a GUI username and password first.

Option 2: docker run

For quick testing, you can also start Syncthing directly with docker run:

docker run -d \
  --name syncthing \
  --hostname my-nas-syncthing \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Asia/Shanghai \
  -p 8384:8384 \
  -p 22000:22000/tcp \
  -p 22000:22000/udp \
  -p 21027:21027/udp \
  -v /path/to/config:/var/syncthing/config \
  -v /path/to/data1:/var/syncthing/data1 \
  --restart unless-stopped \
  syncthing/syncthing:latest

Replace /path/to/config and /path/to/data1 with real host paths.

For example:

1
2

-v /volume1/docker/syncthing/config:/var/syncthing/config
-v /volume1/photos:/var/syncthing/photos

For long-term use, convert this into a Compose file so you do not need to rebuild the full command every time the container is recreated.

Container Paths and Host Paths

Docker beginners often get confused by paths.

For example, this volume mapping:

1
2

volumes:
  - /volume1/photos:/var/syncthing/photos

The left side, /volume1/photos, is the host path. The right side, /var/syncthing/photos, is the path inside the container.

When adding a sync folder in the Syncthing Web UI, the folder path must be the container path:

`1`	`/var/syncthing/photos`

That way Syncthing is actually operating on this host directory:

`1`	`/volume1/photos`

If you enter /volume1/photos in the Web UI, that path usually does not exist inside the container. Syncthing may report an error, or it may create a new directory inside the container filesystem that you did not intend to use.

Persist the Configuration Directory

This line is critical:

`1`	`- ./config:/var/syncthing/config`

Syncthing stores its configuration files, device keys, and index database in the configuration directory. If this directory is not mounted to the host, deleting or recreating the container may change the device ID and invalidate existing device pairings.

Use a stable host path such as:

`1`	`/volume1/docker/syncthing/config`

Do not put the configuration directory in a temporary location, and do not mix it with the actual sync data directories.

Ports and Firewalls

Common ports are:

8384/TCP   Web UI administration
22000/TCP Device sync traffic
22000/UDP QUIC sync traffic
21027/UDP Local discovery

If Syncthing runs on a home NAS, usually check:

whether the NAS firewall allows these ports;
whether Docker bridge port mapping is correct;
whether the router isolates Wi-Fi from wired devices;
whether the phone and computer are on the same subnet.

If Syncthing runs on a cloud server, also check the cloud provider’s security group. In particular, if 22000/TCP and 22000/UDP are not allowed, other devices may only connect through a relay, and the speed will be much slower.

8384 is the administration port. Do not expose it directly to the public internet. If remote administration is necessary, at least set a strong password, and preferably combine it with a reverse proxy, HTTPS, access control, or a VPN.

Permission Issues: PUID and PGID

If Syncthing starts and the Web UI is accessible, but a sync folder reports:

`1`	`Permission denied`

the container process usually does not have read/write permission on the host directory.

Check the UID and GID of the current user on the host:

id

The output may look like this:

`1`	`uid=1000(user) gid=1000(user) groups=1000(user)`

Then set the corresponding values in Compose:

1
2
3

environment:
  - PUID=1000
  - PGID=1000

Also confirm that the host directory itself allows this user to read and write:

`1`	`ls -ld /volume1/photos`

If necessary, adjust the owner or permissions:

`1`	`sudo chown -R 1000:1000 /volume1/photos`

On a NAS, do not blindly run recursive permission changes on an entire shared directory, especially if it is shared by multiple users. A safer approach is to prepare a dedicated sync directory for Syncthing, or grant the corresponding user access from the NAS permission management interface.

First-Time Web UI Security

After the container starts, visit:

`1`	`http://server-ip:8384`

On the first visit, Syncthing usually prompts you to set a GUI username and password. Do not skip this step.

Recommended practice:

set a GUI username and strong password immediately;
do not expose 8384 to the public internet;
use a VPN, SSH tunnel, or controlled reverse proxy for remote access;
if using a reverse proxy, proxy only the Web UI and do not accidentally expose unnecessary ports.

If someone else controls the administration interface, they may be able to add devices, modify shared folders, and change sync relationships. Syncthing encrypts data in transit, but the administration entry point still needs protection.

Add Sync Folders in the Web UI

Take a photo directory as an example. The Compose file already mounts:

`1`	`- /volume1/photos:/var/syncthing/photos`

When adding the folder in the Web UI:

Folder Label: you can use Photos;
Folder ID: use a stable English ID such as photos;
Folder Path: enter /var/syncthing/photos;
Sharing: choose the devices that should receive this folder;
Folder Type: choose Send & Receive, Send Only, or Receive Only based on the data flow.

If this Docker node is the central NAS node, common choices are:

regular documents: Send & Receive;
phone photo collection: Receive Only on the NAS;
outbound distribution folder: Send Only on the NAS.

Choose based on the intended direction of the data. Do not set every folder to bidirectional sync without thinking.

Update the Container

With Compose, updates are usually:

1
2

docker compose pull
docker compose up -d

As long as the configuration directory and data directories are mounted correctly, updating the container will not lose the device ID, pairings, or sync folder configuration.

Before updating, you can back up the configuration directory:

`1`	`tar -czf syncthing-config-backup.tar.gz ./config`

The configuration directory contains device private keys. Do not upload the backup casually to a public location.

Common Issues

Web UI Does Not Open

First check whether the container is running:

1
2

docker ps
docker logs syncthing

Then check port mappings:

`1`	`docker port syncthing`

If the container is healthy but the page still does not open, check the host firewall, NAS firewall, or cloud security group.

Folder Does Not Exist After Adding It

Check whether the path entered in the Web UI is the container path.

For example, if the host path is:

`1`	`/volume1/downloads`

and the container path is:

`1`	`/var/syncthing/downloads`

the Web UI should use the latter.

Only Relay Connections, Very Slow

Check first:

whether 22000/TCP is allowed;
whether 22000/UDP is allowed;
whether router port forwarding is correct;
whether the cloud security group allows both TCP and UDP;
whether the local firewall blocks Docker’s mapped ports.

Relays improve reachability, but they are not suitable for long-term heavy sync traffic.

File Permissions Are Wrong After Sync

First confirm that the container user is correct, then check the host directory permissions. Linux, NAS, and Windows shared folders have different permission models. Do not treat Syncthing as a permission repair tool.

For cross-system sync, try to sync ordinary files and directories. Avoid syncing system folders that depend on complex ACLs, ownership, or extended attributes.

A More Stable Setup

If your goal is to use a NAS or server as the central node, design it like this:

Run Syncthing with Docker on the NAS.
Mount the configuration directory to /volume1/docker/syncthing/config.
Mount each data category separately, for example /volume1/photos and /volume1/notes.
Add the NAS device ID from phones and computers.
Enable file versioning on important folders on the NAS side.
Keep the Web UI accessible only on the LAN or through a VPN.
Back up the NAS independently. Do not treat sync as the only backup.

In this setup, Syncthing handles device-to-device synchronization, the NAS provides always-on availability and version buffering, and real backup is still handled by snapshots, external disks, or off-site backups.

Summary

The key to deploying Syncthing with Docker is separating the container lifecycle from the sync data lifecycle.

The container can be updated, recreated, or migrated at any time. The configuration directory and data directories, however, must remain stable on the host. Use container paths in the Web UI, handle host permissions with PUID, PGID, and directory access rules, and open ports according to the actual network environment.

Once these pieces are clear, Syncthing works very well as a lightweight sync layer between a NAS, a server, and personal devices.

How to Check CVE-2026-42945: Nginx Rift Trigger Conditions, Version Checks, and Upgrade Advice

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 is a security vulnerability in NGINX Open Source and NGINX Plus. It is also being referred to as Nginx Rift. The issue is in ngx_http_rewrite_module, and the vulnerability type is heap-based buffer overflow.

News like this is easy to turn into headlines such as “hidden for 18 years”, “remote control without a password”, or “30% of servers affected”. Those claims travel well, but when reading the patch notes and NVD description, it is better to separate the risk into concrete pieces: the issue is serious, and it does not require a logged-in account; but not every Nginx instance is automatically compromised. Triggering it requires specific rewrite configuration and request conditions.

Start with the official description

The NVD description of CVE-2026-42945 can be summarized as follows:

It affects NGINX Plus and NGINX Open Source.
The vulnerability is in ngx_http_rewrite_module.
The issue may be triggered when a rewrite directive is followed by a rewrite, if, or set directive, unnamed PCRE capture groups such as $1 and $2 are used, and the replacement string contains a question mark ?.
An unauthenticated attacker can send a crafted request to trigger the vulnerability.
The result may be a heap buffer overflow and restart of an NGINX worker process.
If ASLR is disabled on the system, code execution is possible.

F5, as the CNA, gives the following scores:

CVSS v4.0: 9.2, Critical.
CVSS v3.1: 8.1, High.
CWE: CWE-122 Heap-based Buffer Overflow.

So this is not a routine “bad config causes a 404” issue. It is a memory safety vulnerability covered by an official Nginx security fix.

Which claims need context

First, “no password required” is best understood as unauthenticated attack. In other words, the attacker does not need to log in to an Nginx admin panel, obtain SSH access, or hold an application account. But that does not mean every public-facing Nginx instance can be casually taken over.

Second, “direct remote control” depends on conditions. The more careful official framing is that the vulnerability can cause worker process restarts; on systems where ASLR is disabled, code execution is a possible outcome. On environments with ASLR enabled, proper distribution hardening, and restricted runtime privileges, the exploitation path becomes more complex.

Third, “30% of servers affected” should not be treated as “all Nginx market share equals exposed attack surface”. Real exposure depends on the version, whether the affected module is present, whether the specific rewrite configuration exists, whether the distribution has already backported the patch, and how hardened the Nginx runtime environment is.

The more accurate approach is simple: if you run Nginx in production, check it quickly; but do not decide whether you are affected based only on a headline percentage.

How to determine the affected scope

According to nginx.org release information, the nginx-1.30.1 stable release and nginx-1.31.0 mainline release published on May 13, 2026 include multiple security fixes, including the ngx_http_rewrite_module buffer overflow tracked as CVE-2026-42945.

If you use official Nginx source builds or official packages, focus on:

NGINX Open Source stable: upgrade to 1.30.1 or later.
NGINX Open Source mainline: upgrade to 1.31.0 or later.
NGINX Plus: check the fixed version for your F5-supported branch.

If you use Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Alpine, container images, Plesk, control panels, Ingress Controller, or cloud-provider managed components, do not rely only on the upstream version shown by nginx -v. Many distributions backport security fixes into older package versions. The version string may look old while the patch is already included.

One-minute urgency check

Use these questions for a quick risk tiering:

Is this Nginx instance directly exposed to the internet, or is it part of an API Gateway, reverse proxy, load balancer, or Ingress entry layer?
Are you using official Nginx packages, source builds, third-party control panels, or container images without having confirmed the CVE-2026-42945 fix status?
Does the configuration contain complex rewrite rules, especially consecutive rewrite, if, or set directives and unnamed captures such as $1 and $2?
Does any rewrite target include request paths, query parameters, or other user-controlled input?
Is the system weakly hardened, for example with ASLR disabled, overly privileged workers, or overly broad container permissions?

If the first two items apply and rewrite configuration has not yet been reviewed, treat it as high priority. Public entry points, shared environments, Kubernetes Ingress, edge proxies, and Nginx instances carrying login or API traffic should be upgraded or replaced with a confirmed fixed package first.

How to confirm fixes on Debian / Ubuntu / RHEL / Alpine

Distribution users should not look only at nginx -v. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, and Alpine often backport security patches into stable branches, so the visible version may still be lower than nginx.org’s 1.30.1 or 1.31.0.

On Debian / Ubuntu, check security advisories, package changelog, and upgrade candidates:

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

On RHEL / AlmaLinux / Rocky Linux, check security updates and package changelog:

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

On Alpine, check the installed package version and security branch updates:

1
2

apk info -v nginx
apk version -v nginx

If the package manager, distribution security advisory, or vendor advisory explicitly says CVE-2026-42945 is fixed, you can treat it as backported even if the upstream version number looks old. Conversely, if the version looks new but the source is unclear, still confirm the build date and patch source.

How to check container images and Ingress Controller

In container environments, check the Nginx inside the image, not only the host. First confirm the actual embedded version:

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

Also check whether the base image has been updated. If the image is built on Debian, Ubuntu, Alpine, or distribution packages, apply the same advisory and changelog checks for that distribution. Restarting an old image is not useful; the image itself needs to be rebuilt or replaced.

For Kubernetes Ingress, confirm three things:

Whether the Ingress Controller project has published an advisory or fixed release for CVE-2026-42945.
Whether the running controller image digest has actually changed, rather than only the tag.
Whether the controller’s embedded Nginx version, build flags, and template configuration still contain high-risk rewrite rules.

Start by checking the running image:

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

If you use a cloud-provider managed Ingress or gateway, check the corresponding cloud service advisory. Managed components usually cannot be fixed by running apt upgrade yourself; you need the provider’s fix or a switch to a fixed version.

Which rewrite patterns deserve attention

This vulnerability is related to rewrite configuration. Start by searching Nginx configuration:

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

Pay attention to patterns like:

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

The unnamed captures such as $1 and $2, plus the ? in the replacement target, are among the key conditions described by the official sources. During review, pay special attention to:

A rewrite followed by another rewrite, if, or set.
Broad captures such as (.*) and (.+) that are reused as $1 or $2.
Rewrite targets containing ? to append or discard query parameters.
Rewrite input coming from public paths, Host, URI, parameters, or upstream-controlled values.
Rewrite rules generated by panels, gateways, Ingress annotations, or templates.

If you cannot upgrade immediately, use temporary mitigations:

Reduce complex rewrite rules.
Replace unnamed captures with clearer named captures.
Avoid unnecessary ? concatenation in replacement strings.
Add WAF or reverse-proxy rules for high-risk entry points.
Confirm that ASLR is enabled.
Reduce Nginx worker privileges and verify systemd sandboxing, SELinux/AppArmor, and related hardening.

These measures are mitigations, not replacements for patching.

Remediation priority

Prioritize by exposure:

Public-facing Nginx entry points.
Reverse proxies, API Gateway, and edge gateways.
Nginx in multi-tenant environments.
Kubernetes Ingress Controller.
Plesk, control panels, marketplace images, and other components that bundle Nginx.
Internal Nginx instances that carry critical business traffic.

How to verify after upgrading: nginx -t, reload, and worker state

After updating, do not stop at “the package manager succeeded”. Confirm the configuration, process state, and actual binary have all switched over. First validate the configuration:

`1`	`nginx -t`

If there are no errors, reload smoothly:

`1`	`systemctl reload nginx`

If the package upgrade replaced the binary, confirm old workers have exited:

`1`	`ps aux \| grep nginx`

You can also inspect the master process start time and binary path to ensure the running service is not an old process still resident in memory. If needed, schedule a maintenance window and restart the service so old workers or old containers do not continue handling requests.

For containers and Ingress, also confirm the new image rollout has actually completed:

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

The key verification question is not “did the command run”, but “is live traffic now handled by Nginx processes that include the fix”.

Do not ignore the same Nginx security batch

The 1.30.1 and 1.31.0 releases published by nginx.org on the same day fixed more than CVE-2026-42945. The release information also mentions HTTP/2 request injection, SCGI/uWSGI buffer overread, charset module buffer overread, HTTP/3 address spoofing, OCSP resolver use-after-free, and other issues.

That means production environments should not only add a temporary rule for a single CVE. Treat this Nginx security release as an overall upgrade.

Summary

The key point of CVE-2026-42945 is not “all Nginx instances can be instantly taken over”. It is a long-standing memory safety vulnerability in the rewrite module that can be triggered by unauthenticated requests under specific configurations. The most direct result is worker crash and restart; on weaker environments such as systems with ASLR disabled, code execution risk is higher.

For operations teams, the handling order is straightforward:

Confirm the Nginx source and version.
Check distribution, F5, nginx.org, or cloud-provider advisories.
Upgrade to a fixed version or distribution security package as soon as possible.
Review complex rewrite configuration, especially combinations of $1, $2, and ?.
Confirm ASLR, privilege isolation, and service reload state.

The headline can be scary. The fix should be calm: confirm exposure, upgrade, then clean up high-risk rewrite rules.

References

rsync --delete Explained and Practical Directory Cleanup

Sun, 29 Mar 2026 11:00:00 +0800

The core purpose of rsync --delete is to remove files in the target directory that do not exist in the source directory, so both sides stay consistent.

Typical use cases include:

Cleaning stale files on the target side during sync
Quickly emptying a target directory by syncing from an empty source directory

Basic Syntax

`1`	`rsync -a --delete source_dir/ target_dir/`

-a: archive mode, preserves permissions, timestamps, and other attributes
--delete: removes extra files on the target side

Important note: whether source_dir ends with / changes behavior. With /, rsync syncs directory contents; without /, it syncs the directory itself.

Quickly Empty a Target Directory with an Empty Source

If your goal is to keep the directory path but clear all contents, use an empty directory as the source:

# 1) Create an empty directory
mkdir -p /tmp/empty_dir

# 2) Sync and delete target-side content
rsync -a --delete /tmp/empty_dir/ /path/to/target_dir/

In large-directory scenarios, this is often more efficient than deleting files one by one, and it is easier to automate in scripts.

Common Extended Options

--delete-before: delete before transfer, which can be faster in some cases
--progress: show transfer and processing progress

Example (cleaning an Nginx log directory):

`1`	`rsync -a --delete --progress /tmp/empty_dir/ /var/log/nginx/`

Recommendations

Run with --dry-run first to verify the deletion scope
Back up the target directory before running in production
For critical paths, schedule execution during off-peak hours