Daan van Gorkum

CVE-2026-109618 & CVE-2026-109619: Mitigating Critical PHP Session Upload Progress Use-After-Free Vulnerabilities Without Upgrading

2026-10-21T00:00:00Z

If you operate PHP workloads in production—whether behind NGINX and php-fpm, Apache (mod_proxy_fcgi or mod_php), HAProxy, or LiteSpeed (lsphp)—you need to take action immediately to mitigate CVE-2026-109618 and CVE-2026-109619.

Both vulnerabilities are critical Use-After-Free (UAF) flaws in PHP's built-in RFC 1867 session upload progress mechanism (ext/session/session.c) that allow unauthenticated Remote Code Execution (RCE) over a standard HTTP POST request.

Worse still:

session.upload_progress.enabled is turned On (1) by default in upstream PHP and across virtually all major Linux distribution packages (Debian, Ubuntu, RHEL/Rocky, Alpine, and official Docker images).
The vulnerable code executes before your PHP script even starts. Because multipart/form-data parsing happens during the SAPI request startup phase (rfc1867_post_handler), application-level middleware, authentication checks, and runtime ini_set() calls cannot protect you.
Any reachable .php endpoint is a target—even if your application never uses $_FILES, never accepts file uploads, and never calls session_start().

In an ideal world, every team would immediately roll out patched PHP binaries across every node. In reality, not everyone can upgrade PHP right now. Legacy dependencies, pinned container base images, distro backport delays, third-party binary extensions (such as ionCube or proprietary APM agents), and change freezes mean millions of production PHP instances cannot be upgraded overnight.

If you cannot upgrade PHP today, you do not have to wait for a binary patch to neutralize this threat. You can completely sever the attack path right now at the web server, FastCGI, or WAF layer with zero application downtime.

Executive Summary: Take Action Now

Attribute	Details
CVE Identifiers	CVE-2026-109618, CVE-2026-109619
Vulnerability Class	Use-After-Free (CWE-416) leading to Pre-Auth Remote Code Execution (RCE)
Affected Component	PHP `ext/session/session.c` (`php_session_rfc1867_callback`)
Default Exposure	Vulnerable by default (`session.upload_progress.enabled = 1`)
Attack Vector	`multipart/form-data` HTTP `POST` containing `PHP_SESSION_UPLOAD_PROGRESS` stalled across `session.upload_progress.min_freq` (default `1s`)
Fastest Fix (No Upgrade)	Force `session.upload_progress.enabled=0` via `php.ini`, `PHP_ADMIN_VALUE` in NGINX/Apache, and block `PHP_SESSION_UPLOAD_PROGRESS` at the edge/WAF

Understanding CVE-2026-109618 and CVE-2026-109619

To understand why request-level mitigation is mandatory—and why application code cannot block these vulnerabilities—we need to look at how PHP processes multipart/form-data uploads under the hood.

When an HTTP client sends a POST request with Content-Type: multipart/form-data, PHP's SAPI layer invokes rfc1867_post_handler() before compiling or executing the target .php script. If session.upload_progress.enabled is enabled (the default) and the multipart stream contains a form field named PHP_SESSION_UPLOAD_PROGRESS alongside a session identifier (e.g., PHPSESSID), PHP hooks php_session_rfc1867_callback() in ext/session/session.c into the multipart parser events:

MULTIPART_EVENT_START
MULTIPART_EVENT_FORMDATA
MULTIPART_EVENT_FILE_START
MULTIPART_EVENT_FILE_DATA
MULTIPART_EVENT_FILE_END
MULTIPART_EVENT_END

During the upload, PHP maintains a php_session_rfc1867_progress structure holding cached zval* pointers directly into the session's progress HashTable so it can rapidly update byte counters as chunks arrive:

progress->post_bytes_processed (outer progress counter for the overall request)
progress->current_file_bytes_processed (inner progress counter for the active file part)

Periodically—governed by session.upload_progress.min_freq (which defaults to 1 second)—PHP calls php_session_rfc1867_update() to flush progress state to the underlying session storage. When a second update occurs after session.upload_progress.min_freq has elapsed, PHP re-reads and decodes the session data, calling zend_hash_update() on the session array. That update invokes the hash table destructor (HashTable.pDestructor = zval_ptr_dtor) on the previously decoded progress tree—freeing the underlying zval structures while cached pointers in progress still reference them.

CVE-2026-109618: Stale `progress->post_bytes_processed` Pointer Across Multiple Files

In CVE-2026-109618, the outer zval* pointer progress->post_bytes_processed (resolved via zend_hash_str_find on data["bytes_processed"]) is cached once when upload progress tracking initializes and is not refreshed on a subsequent MULTIPART_EVENT_FILE_START.

An attacker initiates a multipart/form-data request with PHP_SESSION_UPLOAD_PROGRESS and begins streaming a first file part, triggering the initial php_session_rfc1867_update().
The attacker stalls the TCP transmission for longer than session.upload_progress.min_freq (1 second).
Upon resuming the stream, a second php_session_rfc1867_update() runs, decoding the session and destroying the previous progress tree via zval_ptr_dtor.
When a second file part arrives, MULTIPART_EVENT_FILE_START refreshes current_file_bytes_processed, but leaves post_bytes_processed pointing to freed memory.
The subsequent MULTIPART_EVENT_FILE_DATA callback executes Z_LVAL_P(progress->post_bytes_processed) = data->post_bytes_processed, performing a write-after-free into the freed heap bin.

CVE-2026-109619: Stale `progress->current_file_bytes_processed` Pointer Within a Single File

In CVE-2026-109619, the vulnerability triggers within a single file upload without requiring a second MULTIPART_EVENT_FILE_START:

progress->current_file_bytes_processed is looked up and cached at MULTIPART_EVENT_FILE_START.
On each MULTIPART_EVENT_FILE_DATA chunk, PHP first writes to both cached pointers (Z_LVAL_P(progress->current_file_bytes_processed) = offset + length and Z_LVAL_P(progress->post_bytes_processed) = post_bytes) and then calls php_session_rfc1867_update().
By stalling the upload stream for longer than session.upload_progress.min_freq (1 second) mid-file, the first post-stall MULTIPART_EVENT_FILE_DATA event triggers php_session_rfc1867_update(), which decodes the session and frees the old progress tree via zval_ptr_dtor.
Because no new MULTIPART_EVENT_FILE_START occurs for the next chunk of the same file, both current_file_bytes_processed and post_bytes_processed remain dangling on the immediately following MULTIPART_EVENT_FILE_DATA event, causing dual use-after-free writes into reclaimed Zend memory allocator (emalloc) bins.

Why Waiting to Upgrade Is Not an Option (And Why `ini_set()` Fails)

Many engineering teams assume they can mitigate PHP configuration issues by adding ini_set('session.upload_progress.enabled', '0'); at the top of index.php or in a framework bootstrap file.

That will not work here.

In PHP's configuration table, session.upload_progress.enabled is registered with the PHP_INI_PERDIR scope—meaning it can only be set in php.ini, .user.ini, php-fpm pool definitions, .htaccess, or web server FastCGI parameters (PHP_ADMIN_VALUE). By the time your PHP script executes ini_set(), the RFC 1867 multipart stream has already been parsed and the use-after-free has already been triggered.

If you cannot immediately upgrade your PHP runtime due to:

End-of-Life or LTS Linux distributions awaiting backported security packages,
Legacy PHP applications (PHP 7.x / 8.0 / 8.1 / 8.2 / 8.3 / 8.4 / 8.5) locked to specific minor versions,
Shared hosting or managed appliances running precompiled lsphp or php-fpm binaries, or
Containerized fleets where rebuilding and validating hundreds of images takes days,

you must disable the vulnerable subsystem or block the trigger at the request / web-server layer today.

Mitigation 1: Zero-Downtime Server-Side Kill Switch (Recommended)

Virtually no modern web application uses PHP's legacy RFC 1867 session upload progress (modern browsers track file upload progress natively on the client side using XMLHttpRequest.upload.onprogress or the Fetch API).

Disabling session.upload_progress.enabled completely bypasses php_session_rfc1867_callback() in ext/session/session.c, neutralizing both CVE-2026-109618 and CVE-2026-109619 with zero functional impact on file uploads or sessions.

Option A: NGINX + PHP-FPM (`fastcgi_param PHP_ADMIN_VALUE`)

You do not even need to touch php.ini or restart php-fpm workers if you inject PHP_ADMIN_VALUE directly from NGINX. Using PHP_ADMIN_VALUE (instead of PHP_VALUE) ensures that no .user.ini file can re-enable the setting:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock; # or your upstream pool

    # Neutralize CVE-2026-109618 & CVE-2026-109619 across all requests
    fastcgi_param PHP_ADMIN_VALUE "session.upload_progress.enabled=0";
}

Test and reload NGINX with zero downtime:

nginx -t && systemctl reload nginx

Option B: Apache (`mod_proxy_fcgi` or `mod_php`)

If you run Apache fronting PHP-FPM via mod_proxy_fcgi, pass PHP_ADMIN_VALUE in the environment:

<IfModule mod_proxy_fcgi.c>
    SetEnv PHP_ADMIN_VALUE "session.upload_progress.enabled=0"
</IfModule>

If you run legacy mod_php (or LiteSpeed reading Apache configuration directives), lock the flag down with php_admin_flag:

<IfModule mod_php.c>
    php_admin_flag session.upload_progress.enabled off
</IfModule>

Gracefully reload Apache:

apachectl configtest && systemctl reload apache2

Option C: HAProxy Native FastCGI (`fcgi-app`)

If HAProxy communicates directly with php-fpm backends over FastCGI (proto fcgi), inject PHP_ADMIN_VALUE inside your fcgi-app definition:

fcgi-app php-fpm-app
    docroot /var/www/html
    index index.php
    path-info ^(/.+\.php)(/.*)?$
    # Disable PHP session upload progress across all FastCGI requests
    set-param PHP_ADMIN_VALUE "session.upload_progress.enabled=0"

backend php_fpm_nodes
    mode http
    use-fcgi-app php-fpm-app
    server fpm1 127.0.0.1:9000 proto fcgi check

Validate and reload HAProxy cleanly:

haproxy -c -f /etc/haproxy/haproxy.cfg && systemctl reload haproxy

Option D: Global `php.ini` and PHP-FPM Pool Configuration

To enforce the mitigation permanently across CLI, FPM, and all SAPIs on the host, drop a dedicated configuration snippet into your PHP conf.d directory (e.g., /etc/php/*/fpm/conf.d/99-disable-upload-progress.ini):

; Mitigate CVE-2026-109618 and CVE-2026-109619
session.upload_progress.enabled = 0

Or lock it inside your PHP-FPM pool configurations (/etc/php/*/fpm/pool.d/www.conf):

php_admin_flag[session.upload_progress.enabled] = off

Mitigation 2: Edge & WAF Request Filtering (Block `PHP_SESSION_UPLOAD_PROGRESS`)

In large multi-tenant environments, reverse-proxy fleets, or appliances where you cannot immediately modify backend FastCGI parameters, you should block any incoming multipart/form-data request attempting to pass the PHP_SESSION_UPLOAD_PROGRESS field (or whatever custom name is configured in session.upload_progress.name).

HAProxy (L7 Request Body Inspection)

When HAProxy fronts your web tier over HTTP/HTTPS, you can enable option http-buffer-request in your frontend or backend and reject multipart/form-data requests containing PHP_SESSION_UPLOAD_PROGRESS before they ever reach an upstream server:

frontend https_edge
    bind :443 ssl crt /etc/haproxy/certs/
    mode http

    # Buffer the incoming request body so ACLs can inspect multipart fields
    option http-buffer-request

    # Match POST multipart/form-data requests containing PHP_SESSION_UPLOAD_PROGRESS
    acl is_post method POST
    acl is_multipart req.hdr(Content-Type) -i -m sub multipart/form-data
    acl has_upload_progress req.body -m sub PHP_SESSION_UPLOAD_PROGRESS

    http-request deny deny_status 403 if is_post is_multipart has_upload_progress

    default_backend web_backends

Tip: HAProxy inspects req.body up to tune.bufsize (default 16384 bytes). Because RFC 1867 requires PHP_SESSION_UPLOAD_PROGRESS to appear before the uploaded file part in the multipart stream so PHP knows to initialize tracking at MULTIPART_EVENT_FILE_START (or if you also increase tune.bufsize 65536 in global), inspecting the buffered request body reliably catches exploit attempts at the edge.

ModSecurity (Apache, NGINX, or OWASP CRS)

Add the following rules to your custom ModSecurity configuration (e.g., REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf or custom-rules.conf):

# Rule 1: Block parsed POST form fields named PHP_SESSION_UPLOAD_PROGRESS
SecRule REQUEST_METHOD "@streq POST" \
    "id:1000101,\
    phase:2,\
    block,\
    status:403,\
    log,\
    msg:'CVE-2026-109618/CVE-2026-109619: Blocked PHP_SESSION_UPLOAD_PROGRESS field',\
    chain"
    SecRule ARGS_POST_NAMES "@contains PHP_SESSION_UPLOAD_PROGRESS" ""

# Rule 2: Inspect raw multipart/form-data body for the Content-Disposition field name
SecRule REQUEST_BODY "@rx name=[\"']?PHP_SESSION_UPLOAD_PROGRESS[\"']?" \
    "id:1000102,\
    phase:2,\
    block,\
    status:403,\
    log,\
    msg:'CVE-2026-109618/CVE-2026-109619: Blocked raw multipart PHP_SESSION_UPLOAD_PROGRESS'"

OpenResty / NGINX with `lua-nginx-module`

If you terminate traffic at OpenResty or NGINX with Lua enabled, you can inspect multipart/form-data bodies at the edge and reject matching requests with 403 Forbidden before they ever reach an upstream PHP worker:

location / {
    access_by_lua_block {
        local content_type = ngx.req.get_headers()["content-type"]
        if content_type and string.find(content_type:lower(), "multipart/form-data", 1, true) then
            ngx.req.read_body()
            local body = ngx.req.get_body_data()
            if not body then
                local body_file = ngx.req.get_body_file()
                if body_file then
                    local f = io.open(body_file, "rb")
                    if f then
                        body = f:read(65536)
                        f:close()
                    end
                end
            end
            if body and string.find(body, "PHP_SESSION_UPLOAD_PROGRESS", 1, true) then
                ngx.log(ngx.ERR, "Blocked CVE-2026-109618 / CVE-2026-109619 exploit attempt")
                return ngx.exit(ngx.HTTP_FORBIDDEN)
            end
        end
    }

    # Standard proxy_pass or fastcgi_pass configuration below
}

Mitigation 3: Reverse Proxy Request Buffering & Timeout Hardening

Both CVE-2026-109618 and CVE-2026-109619 require the multipart upload stream to span longer than session.upload_progress.min_freq (default 1 second) while PHP is actively reading the request body, forcing a mid-stream php_session_rfc1867_update() cycle.

When your reverse proxy fully buffers the client request body on disk/memory before opening the FastCGI or HTTP connection to the PHP backend, PHP receives the entire multipart payload in a single local burst in under a millisecond—preventing the 1-second min_freq window from ever elapsing during rfc1867_post_handler().

NGINX Request Buffering

Ensure that fastcgi_request_buffering and proxy_request_buffering are set to on (the NGINX default, though sometimes disabled by operators for large file upload routes):

http {
    # Buffer the entire client request body before forwarding to PHP-FPM
    fastcgi_request_buffering on;
    proxy_request_buffering on;

    # Enforce strict timeouts against intentionally stalled request bodies
    client_body_timeout 10s;
}

HAProxy Request Buffering & Stall Timeouts

In HAProxy, enabling option http-buffer-request alongside a strict timeout http-request forces HAProxy to wait for the buffered payload within the timeout window rather than trickling stalled chunks directly into an open PHP worker:

defaults
    mode http
    option http-buffer-request
    timeout http-request 5s
    timeout client-fin 5s

Apache `mod_reqtimeout`

If Apache accepts client connections directly without a buffering reverse proxy in front of it, enable mod_reqtimeout to drop connections that intentionally stall mid-body:

<IfModule mod_reqtimeout.c>
    RequestReadTimeout header=10-20,MinRate=500 body=10,MinRate=1000
</IfModule>

Note: Request buffering and timeouts are defense-in-depth measures. Always pair them with Mitigation 1 (session.upload_progress.enabled=0) or Mitigation 2 (WAF filtering), as large uploads over high-latency disks could still cross the 1-second threshold if upload progress remains enabled.

Auditing Your Fleet Right Now

To quickly check whether any PHP installations or FPM pools on a Linux host still have session.upload_progress.enabled active, run this one-liner audit across your servers:

for bin in $(which php php-fpm php-fpm8.1 php-fpm8.2 php-fpm8.3 php-fpm8.4 php-fpm8.5 lsphp 2>/dev/null | sort -u); do
    echo "=== Auditing: $bin ==="
    "$bin" -i 2>/dev/null | grep -E "session\.upload_progress\.(enabled|name|min_freq)"
done

And inspect all php.ini and FPM pool files on disk:

grep -rn "upload_progress" /etc/php* /usr/local/etc/php* /usr/local/lsws/lsphp* 2>/dev/null

Verifying That the Mitigation Is Active

Once you have applied session.upload_progress.enabled=0, verify via a temporary diagnostic check or php -i that both the Local Value and Master Value report Off (0):

session.upload_progress.enabled => Off => Off

If you deployed the WAF or OpenResty rule, test against a staging endpoint with a benign multipart/form-data request containing the PHP_SESSION_UPLOAD_PROGRESS field and confirm that your edge immediately returns HTTP/1.1 403 Forbidden:

curl -i -X POST "https://staging.example.com/index.php" \
  -F "PHP_SESSION_UPLOAD_PROGRESS=test" \
  -F "file=@/dev/null;filename=test.txt"

Frequently Asked Questions (FAQ)

Does disabling `session.upload_progress.enabled` break normal file uploads in PHP?

No. Standard file uploads via $_FILES and move_uploaded_file() are handled by PHP's core RFC 1867 parser (file_uploads = On) and are completely independent of session.upload_progress.enabled. Disabling session upload progress only stops PHP from writing real-time byte counters into $_SESSION["upload_progress_..."] while the upload is in flight.

Are applications that don't use `session_start()` or file uploads still vulnerable?

Yes. When session.upload_progress.enabled=1 is set (the default) and a POST request contains PHP_SESSION_UPLOAD_PROGRESS, PHP automatically initializes the session module during rfc1867_post_handler() before executing the target PHP script—even if that script never calls session_start() or touches $_FILES.

Can I fix CVE-2026-109618 and CVE-2026-109619 using `ini_set()` in my PHP code?

No. Because rfc1867_post_handler() runs during the SAPI request initialization phase prior to script execution, the memory corruption occurs before the first line of your .php script is reached. You must disable session.upload_progress.enabled in php.ini, php-fpm pool configs, or via PHP_ADMIN_VALUE in NGINX/Apache.

Bridging a Cloud Condo Intercom to Home Assistant with Rust, SIP, and MQTT

2026-10-17T00:00:00Z

In a well-tuned smart home, almost every physical interaction is programmable. Lighting scenes adapt to the time of day, climate control reacts to occupancy, and alerts route cleanly through a single dashboard in Home Assistant.

Yet in many modern condominiums in Singapore, one piece of hardware stubbornly resists integration: the building intercom.

Instead of exposing a standard local LAN doorphone inside the apartment, many residential developments route their lobby call panels through cloud-managed property management apps—such as iPlus Living backed by a Fermax MeetMe SIP infrastructure. When a visitor or delivery driver dials your unit from the lobby or side gate, your phone receives a push notification from a proprietary app, you wait for the app to cold-start and negotiate a video stream, and you tap an icon to buzz the gate open.

From a home automation perspective, this is a dead end:

Siloed notifications: You cannot route doorbell events or camera snapshots into Home Assistant notifications, wall tablets, or TVs.
No programmable access: You cannot trigger an unlock from a Home Assistant dashboard, an NFC tag, or a temporary "delivery window" automation.
Single-platform lock-in: Everything depends on a mobile app staying logged in and surviving aggressive mobile OS background battery killers.

I wanted the condo intercom to behave like any other native device in my cluster. So I built iplusliving2mqtt—a self-contained Rust daemon running in Kubernetes that bridges the entire intercom lifecycle into Home Assistant via MQTT Auto-Discovery.

Why Standard SIP Clients Don't Work

At first glance, a SIP-based intercom sounds trivial: grab the SIP credentials, point baresip, Asterisk, or Home Assistant's VoIP integration at the server, and wait for an incoming INVITE.

In practice, inspecting the protocol flow revealed three layers that prevent a standard SIP client from ever receiving a call:

1. Split-Key Encrypted Provisioning API

Rather than giving residents static SIP credentials, the iPlus Living mobile app dynamically provisions them after login. Every HTTP request and response body is encrypted with AES-256-CBC using a fixed initialization vector, while the 32-byte AES key is hidden inside a 42-byte random alphanumeric prefix prepended to the base64 ciphertext (payload[:16] + payload[22:38]).

Authenticating through the four-step login sequence (user/login → user/logindetail → intercom/meetmelicencedetails → intercom/intercomconfiguration) returns:

Cloud MeetMe SIP credentials (sip.fermax.com)
Building PBX SIP credentials (the development's Grandstream server)
The call panel directory (mapping numeric SIP caller IDs like 14 or 22 to human-readable gate and lobby names)

2. The Push Notification Catch-22 (RFC 8599)

Even with valid SIP credentials and an active TLS connection to Fermax's Flexisip proxy (_sips._tcp.sip.fermax.com), a standard SIP client will sit idle forever when someone presses the doorbell.

Why? Because the Flexisip server is configured for mobile push notifications under RFC 8599 with pn-timeout=0:

Contact: <sip:USER@IP:PORT;pn-prid=FCM_TOKEN;pn-provider=fcm;pn-param=SENDER_ID;pn-silent=1;pn-timeout=0;transport=tls>

With pn-timeout=0, the SIP proxy assumes mobile clients go to sleep immediately after registering. When the lobby panel places a call:

Flexisip pauses the incoming INVITE transaction.
It dispatches a high-priority data push (title: "IC_CALL") through Google Firebase Cloud Messaging (FCM) to the pn-prid token registered in the Contact header.
It waits for the client to wake up and send a fresh SIP REGISTER over TLS.
Only after receiving that REGISTER does Flexisip release the held INVITE to the client.

Without a real FCM token and a persistent listener on Google's Mobile Connection Server (mtalk.google.com:5228), the SIP server never forwards the call.

3. Early-Media H.264 Video & Dual-Mode DTMF

Once the INVITE arrives, the lobby panel streams H.264 video during early media (183 Session Progress) before the call is answered. However, the door relay controller ignores unlock commands during early media—to actually buzz the gate open, the client must transition the call to answered (200 OK with SDP), wait for the ACK, and transmit DTMF unlock tones before hanging up (BYE).

System Architecture

To make this rock-solid in Kubernetes without relying on external headless Android emulators, ffmpeg subprocesses, or Python scripts, I built iplusliving2mqtt as a single static Rust binary:

  ┌──────────────────────────┐        ┌──────────────────────────┐
  │    iPlus Living API      │        │   Google FCM / MCS       │
  │  (AES-256-CBC Provision) │        │ (mtalk.google.com:5228)  │
  └────────────┬─────────────┘        └────────────┬─────────────┘
               │ 1. Fetch SIP + Panels             │ 2. Push "IC_CALL"
               ▼                                   ▼
  ┌──────────────────────────────────────────────────────────────┐
  │                      iplusliving2mqtt                        │
  │                                                              │
  │  ┌──────────────────────┐         ┌───────────────────────┐  │
  │  │  Provisioning State  │         │  Native FCM Listener  │  │
  │  │     (state.json)     │         │  (Protobuf over TLS)  │  │
  │  └──────────┬───────────┘         └───────────┬───────────┘  │
  │             │                                 │ Wake Signal  │
  │             ▼                                 ▼              │
  │  ┌────────────────────────────────────────────────────────┐  │
  │  │            Dual-Account SIP/TLS Engine                 │  │
  │  │        (MeetMe Cloud + Building Grandstream)           │  │
  │  └──────────┬─────────────────────────────────┬───────────┘  │
  │             │ RTP H.264 + RTCP PLI            │ SIP Events   │
  │             ▼                                 ▼              │
  │  ┌──────────────────────┐         ┌───────────────────────┐  │
  │  │   OpenH264 Decoder   │────────▶│  MQTT Auto-Discovery  │  │
  │  │   & JPEG Encoder     │         │   & Command Bridge    │  │
  │  └──────────────────────┘         └───────────┬───────────┘  │
  └───────────────────────────────────────────────┼──────────────┘
                                                  │
                                                  ▼
                                      ┌───────────────────────┐
                                      │    Home Assistant     │
                                      │ (Camera, Lock, Ring)  │
                                      └───────────────────────┘

Zero-Touch Provisioning & FCM Emulation

On startup, if no cached state exists on its persistent volume, iplusliving2mqtt performs a two-stage bootstrap:

FCM Registration: Emulates an Android check-in against android.clients.google.com/checkin and registers with Google Cloud Messaging (/c2dm/register3) using the official app's Firebase project parameters to obtain a valid fcm_token.
iPlus Auto-Provisioning: Logs into the iPlus Living API using the resident's email and password, binds the fcm_token, and caches the resulting SIP accounts and call panel directory to state.json.
MCS Stream: Opens a persistent TLS connection to mtalk.google.com:5228 speaking Google's binary MCS framing + Protobuf protocol. The moment an IC_CALL data message arrives, it signals the SIP worker tasks over an internal tokio::sync::mpsc channel to fire an immediate SIP REGISTER.

In-Memory H.264 Keyframe Extraction

Lobby panels stream H.264 video encapsulated in RTP packets (RFC 6184), including fragmented NAL units (FU-A, type 28) and aggregation packets (STAP-A, type 24).

Rather than spawning ffmpeg on every doorbell ring, iplusliving2mqtt handles the media stream directly in memory:

Sends UDP NAT-punching packets plus an RTCP Picture Loss Indication (PLI) and a SIP INFO (picture_fast_update) request immediately upon answering with 183 Session Progress so the panel transmits an IDR keyframe right away.
Reassembles fragmented H.264 NAL units (SPS, PPS, and IDR slices) and feeds the Annex-B bitstream into Cisco's openh264 decoder in memory.
Converts the decoded YUV420p frame to RGB and encodes a JPEG snapshot directly onto the MQTT camera topic (fermax/intercom/snapshot/image) and an HTTP /snapshot.jpg endpoint.

Dual-Mode DTMF Unlock

Different intercom relays along the call path can be picky about how DTMF digits are delivered. When you press the Unlock button in Home Assistant (or when auto-unlock is enabled), the daemon:

Answers the pending INVITE with 200 OK (if still in 183 Session Progress).
Transmits RFC 2833 (telephone-event/8000) RTP payload packets with the end-of-event marker bit and triple redundancy.
Follows up with synthesized in-band G.711 µ-law (PCMU) dual-tone sine waves (697–941 Hz + 1209–1477 Hz) at 8,000 Hz so both digital SIP gateways and analog door strike controllers reliably trigger.
Sends a clean SIP BYE to release the lobby panel.

A Fun Dual-Stack Debugging Quirk: IPv6 vs. IPv4 in SIP

When testing the daemon on a dual-stack host with native IPv6 connectivity, the initial SIP TLS connection to sip5.fermax.com:5223 completed its TLS handshake and then immediately dropped with an EOF.

Digging into the packet trace uncovered two separate issues:

RFC 3261 IPv6 Formatting: sip5.fermax.com publishes both A and AAAA records. Because the host preferred IPv6, tcp.local_addr() returned an IPv6 address. Formatting Via and Contact headers as ip:port without enclosing the IPv6 literal in square brackets ([2a09:...]:5060) caused Flexisip's parser to reject the REGISTER packet immediately.
IPv4-Only Media Relays: Even with bracketed IPv6 headers, the building's local PBX and the RTP audio/video media relays (c=IN IP4 ... in SDP) are strictly IPv4. Because the SIP engine learns its external NAT address from the SIP server's Via: ...;received=<ip>;rport=<port> response header to advertise in the SDP answer, registering over IPv6 leaves the media engine with an IPv6 address that an IPv4 RTP relay can never reach.

Explicitly resolving and selecting IPv4 socket addresses for the SIP/RTP path immediately brought both the MeetMe and Grandstream registrations to 200 OK.

Home Assistant Integration

Because iplusliving2mqtt publishes Home Assistant MQTT Auto-Discovery payloads under homeassistant/#, zero manual YAML configuration is required in Home Assistant. All entities automatically group under a single Fermax MeetMe Intercom device:

Entity	Type	Description
Doorbell Ringing	`binary_sensor`	Turns `ON` the instant an incoming `INVITE` arrives from any gate or lobby panel.
Call State	`sensor`	Tracks the call lifecycle: `idle` → `ringing` → `answered` → `unlocked`.
Last Caller	`sensor`	Displays the resolved lobby or gate name (e.g., Side Gate or Block Lobby) plus JSON attributes.
Intercom Camera	`camera`	Live JPEG snapshot decoded from the panel's H.264 RTP video stream.
Unlock Door	`button`	Immediately answers the active call and sends the DTMF unlock sequence.
Door Lock	`lock`	Reflects `LOCKED` / `UNLOCKED` state and supports standard Home Assistant lock actions.
Auto-Unlock on Ring	`switch`	Optional toggle that automatically answers and buzzes the door open after a configurable delay.

With everything in Home Assistant, a doorbell ring now triggers an instant push notification to our phones with the live decoded camera snapshot attached and an inline "Unlock Gate" action button—plus a temporary "expecting a delivery" toggle that auto-unlocks the lobby gate for the next ring and then turns itself off.

Kubernetes Deployment

True to the rest of my home infrastructure, iplusliving2mqtt is packaged as a minimal multi-stage container (gcr.io/distroless/cc-debian13:nonroot, running as UID 65532 with a read-only root filesystem and all Linux capabilities dropped) and deployed via a Helm chart with /healthz and /readyz probes that verify both MQTT broker connectivity and active SIP registration state.

Fixing Entra ID / Azure AD AADSTS75011 on Ceph Dashboard SAML

2026-10-17T00:00:00Z

While configuring SAML 2.0 Single Sign-On (SSO) for the Ceph Dashboard against Microsoft Entra ID (formerly Azure AD), standard password authentication works out of the box. However, the moment you authenticate with modern, phishing-resistant credentials—such as FIDO2 security keys, Windows Hello, or passwordless MFA—Entra ID rejects the login with AADSTS75011:

AADSTS75011: Authentication method 'MultiFactor, Fido' by which the user 
authenticated with the service doesn't match requested authentication method 
'Password, ProtectedTransport'. Contact the Ceph Dashboard application owner.

At first glance, the error seems backwards: authenticating with a FIDO2 hardware key and MFA is strictly more secure than a password, yet the Identity Provider blocks the session.

Here is why this happens in Ceph and how to fix it cleanly in the Ceph monitor configuration store without patching Python files inside the ceph-mgr container.

Why It Happens: `python-saml` and `RequestedAuthnContext`

Under the hood, the Ceph Dashboard relies on OneLogin's python-saml library to act as a SAML Service Provider.

By default, python-saml initializes its security configuration with:

'requestedAuthnContext': True

Unless overridden, every outbound AuthnRequest generated by the Ceph Dashboard includes an explicit <samlp:RequestedAuthnContext> block demanding PasswordProtectedTransport with Comparison="exact":

<samlp:RequestedAuthnContext Comparison="exact">
  <saml:AuthnContextClassRef>
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

Because Comparison="exact" is enforced, Entra ID checks the exact authentication method used to satisfy the session. When a user signs in with a passkey/FIDO2 token or MFA, Entra ID records the session context as MultiFactor, Fido. Since that does not literally match Password, ProtectedTransport, Entra ID aborts the SAML flow with AADSTS75011.

To allow FIDO2, passkeys, and MFA, Ceph needs to omit <samlp:RequestedAuthnContext> from its AuthnRequest and let Entra ID's Conditional Access policies govern acceptable authentication methods.

The Fix: Updating `ssodb_v1` in the Monitor Store

The ceph dashboard sso setup saml2 CLI command does not expose a flag to toggle requestedAuthnContext, and inspecting ceph dashboard sso show saml2 will show it enabled by default:

$ ceph dashboard sso show saml2 | jq '.onelogin_settings.security.requestedAuthnContext'
true

Instead of modifying sso.py on the container filesystem—which would be wiped on the next container restart or Ceph upgrade—we can patch the serialized SSO database (mgr/dashboard/ssodb_v1) directly in the Ceph monitor config-key store.

1. Export the Current SSO Configuration

Dump the raw JSON configuration from the monitor store:

ceph config-key get mgr/dashboard/ssodb_v1 > ssodb.json

2. Disable `requestedAuthnContext` Under `.saml2`

Ceph stores SAML 2.0 settings under .saml2.onelogin_settings. Use jq to set both requestedAuthnContext and failOnAuthnContextMismatch to false inside .saml2.onelogin_settings.security:

jq '.saml2.onelogin_settings.security += {
  "requestedAuthnContext": false,
  "failOnAuthnContextMismatch": false
}' ssodb.json > ssodb_updated.json

Verify the updated security block before applying it:

$ jq '.saml2.onelogin_settings.security' ssodb_updated.json
{
  "nameIdEncrypted": false,
  "authnRequestsSigned": false,
  "logoutRequestSigned": false,
  "logoutResponseSigned": false,
  "signMetadata": false,
  "wantMessagesSigned": false,
  "wantAssertionsSigned": false,
  "wantAssertionsEncrypted": false,
  "wantNameIdEncrypted": false,
  "metadataValidUntil": "",
  "wantAttributeStatement": false,
  "requestedAuthnContext": false,
  "failOnAuthnContextMismatch": false
}

3. Write the Configuration Back and Reload the Dashboard

Write the updated JSON back to mgr/dashboard/ssodb_v1:

ceph config-key set mgr/dashboard/ssodb_v1 -i ssodb_updated.json

Reload the dashboard manager module so ceph-mgr picks up the new settings from the monitor store:

ceph mgr module disable dashboard
ceph mgr module enable dashboard

Confirm that the active SAML configuration now reflects false:

$ ceph dashboard sso show saml2 | jq '.onelogin_settings.security.requestedAuthnContext'
false

Persistence and Operational Notes

With requestedAuthnContext disabled, SP-initiated logins to the Ceph Dashboard omit the <samlp:RequestedAuthnContext> constraint, allowing Entra ID to complete authentication using FIDO2 security keys, Windows Hello, or MFA without triggering AADSTS75011.

Because the configuration lives in the Ceph monitor database (config-key), it persists across ceph-mgr failovers, container restarts, and node reboots. The only caveat to keep in mind is that running ceph dashboard sso setup saml2 in the future (for instance, when rotating IdP signing certificates) will regenerate the .saml2 dictionary and reset requestedAuthnContext to true—so keep this jq patch in your cluster runbook or configuration management whenever SAML metadata is re-imported.

Why I Built BCRSTracking: Telemetry for Singapore's Bottle Return Scheme

2026-09-12T00:00:00Z

Few things in modern municipal living are as quietly frustrating as carrying two giant tote bags of rinsed plastic bottles and aluminum cans through Singapore's midday heat to your neighborhood supermarket, only to be greeted by a glowing red screen:

Machine Status: Bin Full. Please try again later.

Singapore’s Beverage Container Return Scheme (BCRS) is a fantastic sustainability initiative. Across the island, Reverse Vending Machines (RVMs) accept beverage containers and return deposits. But like any physical infrastructure distributed across hundreds of residential hubs, MRT stations, and supermarkets, real-world machines fill up, experience mechanical jams, or undergo routine maintenance.

As a Site Reliability Engineer, I don't like guessing whether a distributed system is healthy before interacting with it. If a network node has a status, it should have telemetry.

So I built BCRSTracking.

The Upstream API

When inspecting how the official tracking system works (bts.bcrs.sg), it turns out the platform exposes public API endpoints under /forapi/v2/. These endpoints provide:

Location Listings (/locations): A directory of all deployed RVM stations across the island, including operating hours, physical coordinates, and machine identifiers.
Bin Status & Telemetry (/bin-status): Real-time machine operational status, current bin capacity percentage, and hardware availability.

While the data was publicly accessible, there was no historical trend tracking, no differential event stream, and no way to query capacity curves over time to see when specific machines are emptied or filled.

Engineering Requirements

When architecting the tracker, I wanted it to be lightweight, resilient, and polite:

Polite Upstream Concurrency: Never overwhelm public services. Polling must use strict token-bucket rate limiting (golang.org/x/time/rate), bounded worker pools, and exponential backoff with jitter on HTTP 429 or 5xx responses.
Differential State Engine: Instead of blindly dumping snapshots, compute state transitions in memory (MACHINE_ADDED, STATUS_CHANGED, CAPACITY_THRESHOLD_CROSSED) so downstream systems can alert on state changes.
Fast Columnar Analytics: Store telemetry snapshots in ClickHouse using compressed columnar engines (ReplacingMergeTree for current state, MergeTree with TTL for historical bin levels).
Native Observability: Expose Prometheus metrics for scrapers, queue depth, upstream latency, and error rates, scraped by VictoriaMetrics.

System Architecture

The resulting service is written in Go 1.27 and runs as a lightweight container in Kubernetes:

               ┌───────────────────────────────────────────────┐
               │           Upstream BCRS Platform              │
               │            (bts.bcrs.sg/forapi/v2)            │
               └──────────────────────┬────────────────────────┘
                                      │
                                      │ Rate-Limited HTTP/2 (Token Bucket)
                                      │ Exponential Jittered Backoff
                                      ▼
               ┌───────────────────────────────────────────────┐
               │               bcrs-tracker                    │
               │                                               │
               │  ┌─────────────────────────────────────────┐  │
               │  │      Location Poller & Diff Engine      │  │
               │  └────────────────────┬────────────────────┘  │
               │                       │ Active RVM IDs        │
               │                       ▼                       │
               │  ┌─────────────────────────────────────────┐  │
               │  │   Bin Worker Pool (Bounded Concurrency) │  │
               │  └────────────────────┬────────────────────┘  │
               │                       │                       │
               │                       ▼                       │
               │  ┌─────────────────────────────────────────┐  │
               │  │    Batch Writer (500 rows / 5s flush)   │  │
               │  └────────────────────┬────────────────────┘  │
               │                       │                       │
               └───────────────────────┼───────────────────────┘
                                       │ Native Batch Insert (LZ4)
                                       ▼
               ┌───────────────────────────────────────────────┐
               │             ClickHouse Database               │
               │                                               │
               │   • rvm_current        (ReplacingMergeTree)   │
               │   • rvm_events         (MergeTree)            │
               │   • rvm_bin_snapshots  (MergeTree + 2yr TTL)  │
               └───────────────────────────────────────────────┘
                                       ▲
                                       │ SQL / PromQL
                                       │
               ┌───────────────────────┴───────────────────────┐
               │      VictoriaMetrics & Grafana Dashboards     │
               └───────────────────────────────────────────────┘

What the Telemetry Reveals

Having continuous time-series telemetry on reverse vending machines across Singapore reveals fascinating patterns:

The Weekend Surge: Neighborhood machines near residential housing estates typically reach 80–100% capacity on Saturday and Sunday between 2:00 PM and 6:00 PM.
Clearance Cadence: Logistics crews typically clear bins during early morning runs between 7:00 AM and 9:30 AM on weekdays.
Pre-Trip Confirmation: Instead of walking down hoping for the best, I can query my nearest machine via Prometheus/Grafana or a quick API curl to confirm it is operational and has available bin capacity.

Open Source

The entire tracker—including the Go poller, ClickHouse migrations, and Helm charts—is open-source on GitHub:

Repository: github.com/TheDJVG/BCRSTracking

If you're in Singapore and interested in tracking local smart-city infrastructure, feel free to check out the repository, submit PRs, or send me feedback at me@dj.vg.

The 'Datacenter at Home': A Multi-Homed BGP & WireGuard Mesh Architecture

2026-01-31T00:00:00Z

For the past five years, my home network hasn't just been a gateway to the internet; it's been a miniature ISP backbone. While most residential setups rely on a single ISP router doing basic NAT, I wanted something more robust: carrier-grade reliability, deterministic traffic engineering, and seamless multi-homing using my own public Autonomous System Number (AS209792).

By applying hyperscale datacenter design principles—like eBGP-on-the-host and Infrastructure as Code—I’ve built a network that treats residential ISPs as mere transport utilities.

The High-Level Architecture

The core of the network is built on redundancy. I am connected to two primary fiber ISPs in Singapore, MyRepublic and ViewQwest, along with a 5G backup link. Instead of relying on these ISPs for routing, I use them as "underlay" transport to reach my "Upstream Edge Cloud"—a fleet of six VPS nodes (edge1.sin through edge6.sin) hosted across providers.

The edge nodes are the true gateways to the internet. They announce my public prefixes to the global BGP table, while my home Core Router manages the paths between them.

The Connectivity Fabric: WireGuard and Deterministic Addressing

To link my Core Router to the cloud, I use a mesh of WireGuard tunnels. Rather than managing a messy internal IPAM (IP Address Management) database, I use a deterministic addressing logic.

Every tunnel interface is assigned an IPv6 address and a specific UDP listen port generated procedurally based on the IDs of the two nodes. This ensures that the same two peers always get the same IP pair and port, making firewalling and BGP peering definitions completely predictable across the entire mesh. To simplify things further, I utilize RFC 5549, which allows me to carry IPv4 routing information over an IPv6 next-hop, eliminating the need for private IPv4 point-to-point links.

Design Choice: eBGP Everywhere

A common question in BGP design is whether to use internal BGP (iBGP) or external BGP (eBGP). While iBGP is standard for single-ASN networks, it introduces complexity with split-horizon rules and requires Route Reflectors.

I chose the "eBGP in the Datacenter" approach. Every node in my network—the Core Router, the VPS edges, the pfSense firewall, and the Kubernetes nodes—operates under its own unique private ASN (645xx range).

Why this works:

Loop Prevention: BGP’s AS_PATH attribute naturally prevents loops. If a node sees its own ASN in a path, it drops the route.
Observability: I can look at my routing table and instantly see the path a packet took by looking at the sequence of ASNs.
A Clean Public Face: To the internet, I am a single entity. My edge nodes use BIRD (Internet Routing Daemon) with a strict export filter that "scrubs" these internal private ASNs, ensuring the world only sees a clean, single-hop path originating from AS209792.

The Brain: SaltStack & The Salt Mine

Orchestrating this manually would be impossible. I use SaltStack as the network’s "Control Plane." The secret sauce is the Salt Mine, a secure metadata store on the Salt Master.

Metadata Exchange: When a node joins, it generates its own WireGuard keys locally and pushes them, along with its current ISP IP, into the Salt Mine.
Automated Handshakes: All other nodes query the Mine and automatically "wire" themselves to the new peer.
Full System State: Salt doesn't just configure BGP. It manages the entire stack:
- systemd-networkd: Generates .netdev and .network files for the tunnels.
- Firewalling: Automatically opens the procedurally generated UDP ports only for authorized peers.
- BIRD: Templates the BGP sessions and filters.
- Kubernetes: Peering pfSense with the K8s nodes so that Pod/Service IPs are reachable across the entire network without NAT.

Reliability and Convergence

With residential ISPs, "silent failures" (where the link is up but traffic is blackholed) are a reality. To counter this, every BGP session runs BFD (Bidirectional Forwarding Detection). If a link drops even a few packets, BFD detects the failure in milliseconds and BGP reroutes traffic to a healthy ISP.

As a final failover, the 5G link is configured with heavy AS-path prepending. It stays in standby, receiving no traffic, until every other fiber path is exhausted.

Conclusion

This setup has been rock-solid for over five years. By moving the "intelligence" into SaltStack and using BGP for what it does best—path selection—I've created a home network that behaves like a professional datacenter fabric. It’s stateless, modular, and can scale to a new cloud provider with a single state.apply.

Easy and free Dynamic DNS

2025-10-04T00:00:00Z

The nasty need for dynamic DNS.

For a while now I've been maintaining a couple of 4G/5G enabled out of band devices. These devices are used to provide access to serial consoles of network devices. Why you ask? Well, sometimes a configuration error or something else causes the normal access paths to be unavailable. Who hasn't made a L2 loop by accident...

I call these devices "last resort". They provide a last resort access to my network when everything else fails, and they use 4G/5G for connectivity. The downside? They don't have a fixed IP address, quite often the IPs change. For most cases this is fine because I have reverse tunnels, but I still want to access them in case those fail. But for that to work I need to know 1 crucial thing: its IP address on the internet.

I'm sure many people have used a service like "dyn.com" to solve this problem, the device in question sends a HTTP request (we wish those devices support HTTPS...) and a DNS record gets updated with the IP of the requesting device. That way every time the IP changes the DNS record gets updated and we can access it using the DNS name and it makes it easy to monitor its availibility. The main problem I had with this solution is the cost (also the annoying ratelimiting, but I partially blame the devices in question), it was not worth the money to use "dyn.com" for something I can make myself, right?

So I made a service myself.

When I started to think about this had the following requirements: - Dead simple to request a new dynamic hostname - No need for accounts - Compatibility with DynDNS style updates (/nic/update) (more to add?)

When I had the requirements clear I also wanted to make it stateless, who wants to keep track of what hostnames are in use and not? If you lose the credentials, just get a fresh hostname. I quickly wrote an implementation using FastAPI and looked in my unused domain invenstory for a good candidate.

I present to you: XYZ.FRL

Now the initial version of this service is deployed I really like it myself, mainly because how simple it is. You want to know how simple? Open your terminal and come along.

Request a new dynamic hostname

› curl -s https://xyz.frl/generate | jq .
{
  "hostname": "4bd36fd6538b45b3b5449e615afc8e21.xyz.frl",
  "username": "4bd36fd6538b45b3b5449e615afc8e21",
  "password": "+MihUvQ8pc1QwYA6/16A/D/155qHfJKlUqUhNgD6osE="
}

Update the hostname with a new IP

Simple use curl to send an update request and set the ip to the valuse set in the myip query param (you can also leave it out to use the IP the request is coming from).

› curl -s --user '4bd36fd6538b45b3b5449e615afc8e21:+MihUvQ8pc1QwYA6/16A/D/155qHfJKlUqUhNgD6osE=' 'http://xyz.frl/nic/update?myip=192.0.2.0,100::'

Check your new IP!

It might take a brief moment for changes to propagate

› host 4bd36fd6538b45b3b5449e615afc8e21.xyz.frl
4bd36fd6538b45b3b5449e615afc8e21.xyz.frl has address 192.0.2.0
4bd36fd6538b45b3b5449e615afc8e21.xyz.frl has IPv6 address 100::

Profit.

From now simply use your compatible client (or curl) with our without the myip query param to update the IP address in the record. Make your own life easy by simply CNAMEing to this hostname and you should be good to go.

Final thoughts

This was a small fun project that I threw together on a Saturday morning when I got a renewal notice (and now cancellation) for DynDNS. I hope it can benefit others too.

Do you have any ideas to make this service even better? Contact me on me@dj.vg.

Security

While I've applied pretty aggressive rate limiting (1 request per minute on the generate and update endpoints) it's of course possible people might try to abuse this, if that happens I'll deal with it.

Timelapse system: a start

2022-01-25T00:00:00Z

Everyone that’s interested in technology will at some point face the same struggle: how do I apply all these interesting technologies in my own projects.

This is really the start of a system that (at the moment of writing) stores over 750 thousand photos occupying 6.2 terabyte of storage and every single minute this grows.

In the following comparison you can see a picture taken just after I started this project and one that has been taken on the day of publishing this piece.

Just after starting the project

Day of publishing

Times are changing

I’m living in an area that’s actively being developed and for some reason I can’t let go of the past. I want to keep track of how the area is changing and feel nostalgic on “how thing once were”. This is why is decided to put a camera on my balcony, with a Raspberry Pi and a Cronjob to take a picture every single minute using gPhoto2. The pictures would be saved on a simple NFS share backed by 2 times 1TB hard disks in raid 1. That was it. Anyone working in IT will immediately see a couple of problems with this approach, just to name a couple:

Reliability
Monitoring
Observability

Reliability

As I was not actively looking at the pictures it would happen multiple times that the Raspberry Pi was hanging or that for some reason the camera was not responding ending up with thousands of hanging Cronjobs. Also unreliable Wifi from outdoor made NFS very sad. That had to change, it should just work, even if one of the components is not working.

Monitoring

As mentioned in the previous paragraphs I was not aware of these problems. It was just (not) running and that is not great for a project that tries to capture a changing landscape one minute at a time. The moment there’s a problem with the setup I want to know about and preferable it should recover automatically (by for example resetting the power of the camera).

Observability

Taking a photo is one thing, but there’s so much extra information that I was not aware of. Some of the information is obvious, for example the ISO and exposure, which is stored in the Exif portion of the file. Other information that I wanted to store was: Outside temperature and relative humidity, how much time is spend on the camera, how reliable is this process, how long does it take to write the file to storage, and how much energy does all of this consume!

How to get there

In the blogs after this I will write down exactly how I got to a system that I almost never have to touch. How videos are automatically created daily. How the camera and controller is able to recover from almost any failure, how data is stored and replicated to the other side to the world.

So if you’re interested in Kubernetes, Ceph (and its S3 compatible API radosgw), Django, VictoriaMetrics (and metrics in general), Home Assistant, and many more (don’t forget the hardware). Come back soon to see how all of these things are combined to create a system that allows me to take reliable pictures that I plan to store forever!

Daan van Gorkum

CVE-2026-109618 & CVE-2026-109619: Mitigating Critical PHP Session Upload Progress Use-After-Free Vulnerabilities Without Upgrading

Executive Summary: Take Action Now

Understanding CVE-2026-109618 and CVE-2026-109619

CVE-2026-109618: Stale progress->post_bytes_processed Pointer Across Multiple Files

CVE-2026-109619: Stale progress->current_file_bytes_processed Pointer Within a Single File

Why Waiting to Upgrade Is Not an Option (And Why ini_set() Fails)

Mitigation 1: Zero-Downtime Server-Side Kill Switch (Recommended)

Option A: NGINX + PHP-FPM (fastcgi_param PHP_ADMIN_VALUE)

Option B: Apache (mod_proxy_fcgi or mod_php)

Option C: HAProxy Native FastCGI (fcgi-app)

Option D: Global php.ini and PHP-FPM Pool Configuration

Mitigation 2: Edge & WAF Request Filtering (Block PHP_SESSION_UPLOAD_PROGRESS)

HAProxy (L7 Request Body Inspection)

ModSecurity (Apache, NGINX, or OWASP CRS)

OpenResty / NGINX with lua-nginx-module

Mitigation 3: Reverse Proxy Request Buffering & Timeout Hardening

NGINX Request Buffering

HAProxy Request Buffering & Stall Timeouts

Apache mod_reqtimeout

Auditing Your Fleet Right Now

Verifying That the Mitigation Is Active

Frequently Asked Questions (FAQ)

Does disabling session.upload_progress.enabled break normal file uploads in PHP?

Are applications that don't use session_start() or file uploads still vulnerable?

Can I fix CVE-2026-109618 and CVE-2026-109619 using ini_set() in my PHP code?

Bridging a Cloud Condo Intercom to Home Assistant with Rust, SIP, and MQTT

Why Standard SIP Clients Don't Work

1. Split-Key Encrypted Provisioning API

2. The Push Notification Catch-22 (RFC 8599)

3. Early-Media H.264 Video & Dual-Mode DTMF

System Architecture

Zero-Touch Provisioning & FCM Emulation

In-Memory H.264 Keyframe Extraction

Dual-Mode DTMF Unlock

A Fun Dual-Stack Debugging Quirk: IPv6 vs. IPv4 in SIP

Home Assistant Integration

Kubernetes Deployment

Fixing Entra ID / Azure AD AADSTS75011 on Ceph Dashboard SAML

Why It Happens: python-saml and RequestedAuthnContext

The Fix: Updating ssodb_v1 in the Monitor Store

1. Export the Current SSO Configuration

2. Disable requestedAuthnContext Under .saml2

3. Write the Configuration Back and Reload the Dashboard

Persistence and Operational Notes

Why I Built BCRSTracking: Telemetry for Singapore's Bottle Return Scheme

The Upstream API

Engineering Requirements

System Architecture

What the Telemetry Reveals

Open Source

The 'Datacenter at Home': A Multi-Homed BGP & WireGuard Mesh Architecture

The High-Level Architecture

The Connectivity Fabric: WireGuard and Deterministic Addressing

Design Choice: eBGP Everywhere

Why this works:

The Brain: SaltStack & The Salt Mine

Reliability and Convergence

Conclusion

Easy and free Dynamic DNS

The nasty need for dynamic DNS.

So I made a service myself.

I present to you: XYZ.FRL

Request a new dynamic hostname

Update the hostname with a new IP

Check your new IP!

Profit.

Final thoughts

Security

Timelapse system: a start

Times are changing

Reliability

Monitoring

Observability

How to get there

CVE-2026-109618: Stale `progress->post_bytes_processed` Pointer Across Multiple Files

CVE-2026-109619: Stale `progress->current_file_bytes_processed` Pointer Within a Single File

Why Waiting to Upgrade Is Not an Option (And Why `ini_set()` Fails)

Option A: NGINX + PHP-FPM (`fastcgi_param PHP_ADMIN_VALUE`)

Option B: Apache (`mod_proxy_fcgi` or `mod_php`)

Option C: HAProxy Native FastCGI (`fcgi-app`)

Option D: Global `php.ini` and PHP-FPM Pool Configuration

Mitigation 2: Edge & WAF Request Filtering (Block `PHP_SESSION_UPLOAD_PROGRESS`)

OpenResty / NGINX with `lua-nginx-module`

Apache `mod_reqtimeout`

Does disabling `session.upload_progress.enabled` break normal file uploads in PHP?

Are applications that don't use `session_start()` or file uploads still vulnerable?

Can I fix CVE-2026-109618 and CVE-2026-109619 using `ini_set()` in my PHP code?

Why It Happens: `python-saml` and `RequestedAuthnContext`

The Fix: Updating `ssodb_v1` in the Monitor Store

2. Disable `requestedAuthnContext` Under `.saml2`