DEV Community

Management was never a promotion

Matt Cockayne — Sun, 04 Oct 2026 02:05:40 +0000

The man who hired me into one of my more recent jobs opened the interview with a question I've never quite managed to forget: why did I want a job I was clearly overqualified for?

I don't remember my answer word for word. I do remember thinking it was a perfectly fair question, if you read a CV the way most companies draw their org chart... with management sat on the top and everything else somewhere underneath it.

The ladder most places draw

You'll know the shape. Junior, mid, senior, maybe a lead if you're lucky, and then the engineering rungs just sort of stop. Anything above that has "manager" or "head of" in the title, so the only way to keep going up is to stop doing the thing that got you there in the first place. Plenty of very good engineers take that step because it's the only step on offer, and some of them find they love it, and some of them find out a year later that they've swapped a job they were brilliant at for one they never wanted (the Peter principle, more or less, with a pay rise to soften the landing).

I don't think management is the villain in that story. It's a proper job, and a hard one, and I've done enough of it to know it has burdens the engineering side never sees. My problem is with the drawing. Management and engineering are two sides of the same coin, and far too many companies prioritise the management track and simply forget there's no cap on the engineering one. Management is a choice. It was never a promotion.

The cap I built myself

The first time I hit that ceiling, the daft thing is I'd put it there myself.

I started my own boutique digital agency, Zucchi, and became its MD, which was a choice and a big one. It also pushed me about as far away from engineering as I've ever been and flooded my brain with management problems. It turns out being MD of a small company is mostly sales and HR, with a bit of engineering squeezed in round the edges if you're lucky, and (as I've written about before) while I like to think I'm a decent engineer, I'm a shit salesman.

What I learned there wasn't that management is bad. I was good at a lot of it! It was that the two jobs pull in different directions, and trying to be both at once, in one role, is a very hard thing to reconcile. The top of the only ladder in the company was a job I'd never have applied for... and I'd drawn that ladder myself.

A channel, not a waiting room

Every company where I've had any say since, I've pushed for a fully fledged engineering channel, so people can keep growing without being shoved into management to do it. The titles varied from company to company, but the point was always the same: a way up that doesn't go through a management role.

And that's also where I learned the other half of the problem, which is that everybody chases the title. I find this massively frustrating. We'd take on graduates straight out of university as juniors, and within twelve to twenty-four months a fair few of them would either be declaring they should be made senior, or leaving for somewhere that would hand them the word, as if the engineering track was a quick route up just by turning up for long enough.

That properly incensed me. Growth should be something you can show, from the effort you put in and the value you bring to the team, and time served is neither of those. A track with no cap isn't a waiting room where the titles come round on a timer. It needs the rungs written down, so that everyone (the engineer, their lead, the person signing off the pay rise) can point at what senior actually means and see whether you're doing it.

What it looks like done properly

Since then I've gone looking for companies that write that combination of effort and value down, and Axon did it really well. Their engineering ladder didn't stop at senior. It carried on past Senior Software Engineer II to Staff Engineer, then Principal, then Distinguished Engineer, three more rungs past the point where a lot of companies simply run out of ladder, and each one had its expectations written down and sat level with a role on the management side, all the way up to just under the C-suite. An engineer there could keep climbing for a whole career without ever having to manage anybody.

Axon is where I was asked that interview question, as it happens, and I took the job on the engineering side of the coin, on purpose. Years of running teams didn't make it a step down, whatever the CV looked like from the outside. (For the record I sat a rung lower than the work I was actually doing, which was more like the two above it. A ladder can be beautifully drawn and still be read wrong.)

Same number on both sides

Now, the man who asked me that question was one of Axon's longest-serving infrastructure engineers, a seriously skilled one with a whole career of it behind him, and somewhere along the way management had been thrust upon him rather than chosen. He was damn good at it, too. He took all that engineering and turned it into real engineering management. He could handle a room full of stakeholders, he knew what a team could actually carry, and he knew when a deadline was nonsense, because he'd been the one at the keyboard for most of his working life.

He got scapegoated anyway, more than once, for problems that were really about a small team being handed a big job without the people to do it, and eventually he switched back to the engineering track. Everyone around him treated it as a demotion.

What still makes me laugh (in a slightly hollow way) is that on paper it wasn't one. He'd been a manager at one level, and he went back to being an engineer at exactly the same level. Same number on both sides. By the company's own ladder it was a sideways step, a coin turned over... and the people around him read it as a fall anyway, because they wanted to.

So even a really well-written ladder isn't proof against people. Axon had about the best engineering path I've worked inside, and folk were still able to bend it to suit their own agendas... writing the rungs down is necessary, it just doesn't stop anyone reading them upside down.

He asked me, all those months earlier, why I wanted a job I was clearly overqualified for. I'd just picked which side of the coin I wanted facing up.

He's since picked neither. His years at Axon paid off rather nicely in the end, and he's taken early retirement, so as far as I'm concerned the last laugh is his... even if it does mean the industry lost a fantastic engineer and an exceptional manager in one go. Turns out you can land the coin on its edge after all.

Originally published at phpboyscout.uk on 4 October 2026.

Designing a 99.999% IoT Platform

beefed.ai — Sun, 04 Oct 2026 02:05:25 +0000

The symptoms are familiar: device fleets that flood your broker after a region blip, firmware campaigns that stall because the device registry is quarantined, and business teams escalating because analytics lose a window of truth during maintenance. You get paged at 03:00 to manually re-route traffic, and the postmortem shows the same root causes as last quarter: single-region control plane, opaque dependency maps, and brittle runbooks.

Contents

Why 99.999% uptime is non-negotiable for real-world IoT fleets
Architectural patterns that actually deliver five nines
How to build a resilient multi-region deployment and DR plan
How to prove resilience: failover testing, chaos engineering, and contractual SLAs
Designing observability and alarms without bankrupting the project
Operational runbooks, checklists, and templates you can use in 48 hours

Why 99.999% uptime is non-negotiable for real-world IoT fleets

Five nines means roughly 5.26 minutes of downtime per year, and that hard number shapes what counts as “acceptable” risk on every device lifecycle operation and release window. Your SLO is the control you hand to the business; the error budget is the throttle on feature churn. Use the error-budget model from SRE to make reliability decisions objective and repeatable: you convert availability percentages into minutes, allocate that budget, and let the budget drive release policy and tickets for remediation.

For IoT, availability has second-order effects that are uniquely painful:

A downed device registry means new or replaced devices cannot authenticate — field technicians stop working.
Lost ingestion windows create holes in digital twins and analytics, producing stale commands.
Regulatory and safety exposure in OT/industrial contexts can translate downtime into fines or injury.

Make availability your primary non-functional requirement when the platform is used for control, billing, or safety. Architecture follows from that requirement.

Architectural patterns that actually deliver five nines

You must stop thinking in “single-region” terms and design with the expectation of partial, intermittent, and correlated failures.

Key high-availability building blocks I use at scale:

Decouple ingestion with durable queues: use an event log (e.g., Kafka/Kinesis) as the canonical ingestion buffer so downstream consumers can be scaled or recovered without losing telemetry.
Stateless front ends, stateful long-term stores: keep connection brokers and ingestion stateless (easy to scale), and push durable state to geo-replicated stores.
Active-active for critical flows; warm standby for the rest: reserve active-active for control-plane endpoints or customer-facing APIs that need near-zero RTO; use warm standby for analytics pipelines to balance cost and recovery time.
Device registry as the single source of truth: the device registry must be designed for cross-region access or reliable replication; store immutable device identity attributes and use per-region caches for read performance with deterministic reconciliation for writes. AWS IoT’s registry and Device Shadow primitives are useful references for capabilities you’ll need.
Digital twin separation: keep the fast device twin (Device Shadow) close to the device for command-and-control and replicate aggregated twin state to a graph/analytics twin (e.g., Azure Digital Twins) for business logic and historical analysis.

A compact comparison helps align trade-offs:

Strategy	Typical RTO	Typical RPO	Relative Cost	When to pick
Active‑Active (multi‑region)	Seconds	Near‑zero	High	Control-plane and customer-facing APIs
Warm‑Standby (hot spare)	Minutes	Seconds–minutes	Medium	Ingestion, near-real-time analytics
Pilot‑Light	Tens of minutes–hours	Minutes	Low–Medium	Non-critical analytics and batch jobs
Backup & Restore (cold)	Hours–Days	Hours–Days	Low	Archival systems, cost-sensitive workloads

These categories and the suggested actions come from well‑architected disaster-recovery guidance and event-driven DR patterns used in cloud best practices.

Practical engineering rules I follow:

Make the control plane (provisioning, cert rotation, ACLs) independently recoverable from the data plane (telemetry ingestion).
Require idempotent ingestion: every device message has a stable identifier or sequence so retries never create corruption.
Design device behavior for graceful backoff and exponential reconnect with jitter; never let a reconnect storm take down the broker.

How to build a resilient multi-region deployment and DR plan

Multi‑region design isn’t optional when you target five nines. You must choose where to spend money (and where not to).

Core considerations and patterns:

Global traffic steering vs DNS TTL: DNS failover is cheap but slow; global load balancers or services like AWS Global Accelerator / Azure Front Door provide rapid regional failover or weighted routing with health probes. Use them for customer-facing endpoints.
Per-region ingestion endpoints: expose region-local MQTT/WebSockets endpoints so devices connect to the nearest ingress. Replicate events asynchronously to central processing with durable logs for replay and recovery.
Registry replication approaches:
- Strongly replicated global DB (DynamoDB Global Tables-style) gives near‑real-time updates everywhere at higher cost and complexity.
- Primary region with async replication reduces cost but increases write RPO and requires conflict resolution. Choose based on whether device onboarding or device command integrity is more critical.
Data replication for analytics: use change-data-capture (CDC) or event-stream replication into your analytics fabric so a region loss doesn’t create a permanent gap.
Network partitions and split brain: define clear leader election rules and write-shard boundaries. Don’t let two regions accept diverging desired state commands without reconciliation.

Design checklist for a multi-region DR plan:

Document RTO and RPO per service and per device class.
Map dependencies (auth, registry, ingestion, processing, downstream APIs).
Choose a DR pattern per dependency (active-active, warm-standby, pilot-light).
Automate failover steps (route updates, promote DB writer, increase consumer scaling).
Schedule and run non-production failover drills and maintain runbook automation.

How to prove resilience: failover testing, chaos engineering, and contractual SLAs

You can’t claim five nines unless you measure it — and you can’t measure it unless you test it under realistic failure modes.

Run your GameDays and scheduled failovers: simulate region loss, induce load spikes, and rehearse full failover runbooks in staging. Azure’s IoT Hub documentation recommends using non‑production environments to validate region failover behavior because region failover can cause data loss and downtime during tests.
Adopt chaos engineering for continuous assurance: inject faults targeted at dependencies (broker nodes, database replicas, network latency) and verify automated recovery. Gremlin has a practical catalog for failure modes and regulatory use cases; Netflix’s Chaos Monkey is the origin story and still useful as an operational pattern.
Make SLOs and error budgets your operational control loop: tie release velocity to remaining error budget and require postmortems when incidents exceed threshold consumption. Use the SRE error-budget model to agree with product teams on the trade-offs between features and stability.

Concrete failover testing protocol (short):

In staging, trigger a simulated region outage (network blackhole + terminated ingestion nodes).
Execute automated runbook to re-route traffic to secondary and promote writable endpoint.
Stream a golden dataset through the platform to verify no message loss and correct digital twin state reconciliation.
Measure RTO, RPO, and user-impacted SLIs; log and create P0 actions for any divergence.

Sample PromQL SLI (availability) to implement as a production SLI:

# percentage of successful ingestion requests over 5m window
100 * (1 - sum(rate(iot_ingest_requests_total{job="ingest",status=~"5.."}[5m])) / sum(rate(iot_ingest_requests_total{job="ingest"}[5m])))

Prove, measure, and codify: a test that runs once but is not automated will be forgotten.

Designing observability and alarms without bankrupting the project

Observability is the lever: good metrics let you detect failures before they cascade; bad metrics produce pager noise and cost overruns.

Instrumentation strategy:

Use a vendor-neutral tracing and metric layer like OpenTelemetry for traces, metrics, and context propagation across services.
For metrics at scale, avoid centralizing raw Prometheus scraping across regions. Use remote_write into a global long-term store (Thanos / Grafana Mimir / Cortex) or aggregate per-region before global query. This balances latency, availability, and cost.
Favor SLO-driven alerts: page on SLO breach probability, not on raw 5xx counts. Route different alert levels to different channels (ops, engineering, product) and attach runbook links to alerts.
Implement sampling and downsampling: keep high-cardinality traces for 1–2 weeks, metrics for 90 days with downsampled aggregates thereafter, and logs for a short window unless flagged for retention.

Example Prometheus remote_write snippet (agent-mode):

global:
  scrape_interval: 15s

remote_write:
  - url: "https://thanos-receive.us-east-1.example.com/api/v1/receive"
    # secure it with mTLS or basic_auth in production
scrape_configs:
  - job_name: 'iot_broker_exporter'
    static_configs:
      - targets: ['broker-us-east-1:9100']

Cost trade-offs to manage:

High-cardinality metrics and long retention both drive storage and query cost — prefer aggregation at the edge.
Synthetic checks are cheap and high-value; instrument heartbeats from brokers and core services.
Use alerts with escalation windows and deduplication to protect on-call from storms.

Important: Treat iot monitoring as a product: agree SLIs with your stakeholders, instrument them precisely, and fund observability like you fund production capacity.

Operational runbooks, checklists, and templates you can use in 48 hours

This is a pragmatic playbook you can execute quickly.

SLO & policy checklist

Define SLOs by product slice (control-plane, ingest API, device provisioning). Document measurement windows and error-budget policy.
Create an SLA template using the SLO as the objective and list remedies for breach.

Critical DR runbook template (short form)

Trigger: Detect region-wide loss of ingestion (all health checks failing for > 30s).
Owner: Platform On-Call (primary).
Steps:
- Promote secondary ingestion writer / change DB writer endpoint.
- Update global routing weights to route 100% traffic to secondary (or flip failover DNS).
- Validate device heartbeats and device registry reads (run curl health endpoints).
- Run golden-data replay for last 5 minutes and reconcile digital twin deltas.
Post‑incident: Conduct postmortem with action items, link to runbook and error-budget consumption.

Emergency runbook quick-table

Action	Owner	Target
Flip load-balancer routing to secondary	Platform SRE	< 5 minutes
Promote DB writer / failover	DB team	< 10 minutes
Validate device registry reads	App owner	< 15 minutes
Start telemetry replay and reconciliation	Data eng	< 30 minutes

GameDay quick script

Week 0: Run a smoke failover in staging for a single critical device group.
Week 4: Run a full region simulated outage in staging and execute full runbook.
Quarterly: Run a cross-team GameDay with customers/integrations invited to validate SLAs and communications.

Minimal automation to prioritize

Make failover routing a one-click / CI-driven operation (no manual SSH edits).
Keep infrastructure-as-code (terraform/arm/bicep) for all routing and DNS changes.
Wire alerts to a runbook link that includes exact commands and audit checklists.

Closing

Designing for 99.999% uptime forces you to make repeatable decisions: define your SLOs first, split control and data planes, choose an appropriate multi-region DR pattern, automate failover, and instrument aggressively with SLO-driven alerts. Start by locking the device registry and critical SLOs into code, schedule your first GameDay, and use the error budget as the single lever to balance reliability and change.

Sources:
What is five-nines uptime? - Explains five-nines availability and the calculation of downtime per year.

Embracing risk and reliability engineering (Google SRE) - SRE guidance on SLOs, error budgets, and operational policy.

Reliability in Azure IoT Hub (Microsoft Learn) - Details IoT Hub regional replication, manual failover guidance, and testing recommendations.

Managing things with the registry - AWS IoT Core (Docs) - Registry, Device Shadow, and device management patterns in AWS IoT.

Chaos Engineering — Gremlin - Use cases and practices for chaos engineering and GameDays.

Implementing Multi-Region Disaster Recovery Using Event-Driven Architecture (AWS Architecture Blog) - Reference architecture for event-driven multi-region DR.

Develop a disaster recovery plan for multi-region deployments — Azure Well-Architected - DR strategies (active‑active, warm standby, pilot light) and validations.

OpenTelemetry Documentation - Vendor-neutral observability framework, Collector and instrumentation guidance.

Prometheus Monitoring for Multi-Region Applications (BinaryScripts) - Federation vs remote_write, Thanos/Cortex patterns for global metrics.

Grafana Mimir (GitHub) - Scalable, multi‑tenant long-term storage for Prometheus-compatible metrics.

Netflix Chaos Monkey (GitHub) - Historical reference and open-source tooling for chaos engineering.

What is Azure Digital Twins? (Microsoft Learn) - Digital twin concepts and integration with IoT Hub for modeling and event routing.

I Traced CrewAI's Sandbox CVE: 9 Names Missed the Runtime

Kiell Tampubolon — Sun, 04 Oct 2026 02:01:22 +0000

A CVE published yesterday afternoon says the Python sandbox in CrewAI, a widely used agent framework, blocked nine module names and still lost. The record's wording is blunt for a CVE: the blocklist "operates at the wrong level of abstraction." The escape it describes never uses an import statement at all.

I was researching agent sandbox failures this week anyway. Between the GreyNoise agent swarm report, the SGLang pickle RCE last weekend, and Bengio's agent-misbehavior paper trending on Hacker News, every feed I follow is agent security right now. When my trending scan surfaced CVE-2026-37008 this morning, I searched for writeups and found none. Zero HN threads, zero Dev.to posts, no news pickup. So I pulled the NVD record, the MITRE CNA data, and the fix commit from GitHub, and read all three. Here is what the record says, what the vulnerable code actually did, why the fix deletes the feature instead of extending the list, and three checks worth running on any sandbox your agent framework ships.

This is the entire security model the CVE is about, verbatim from the pre-fix source:

# From crewai-tools code_interpreter_tool.py, pre-fix source (SandboxPython)
BLOCKED_MODULES = {"os", "sys", "subprocess", "shutil",
                   "importlib", "inspect", "tempfile",
                   "sysconfig", "builtins"}

def restricted_import(name, *args, **kwargs):
    if name in SandboxPython.BLOCKED_MODULES:
        raise ImportError(f"Importing '{name}' is not allowed.")
    return __import__(name, *args, **kwargs)

Nine names. One string comparison. Keep that in mind while we walk the record.

What does CVE-2026-37008 actually say?

Start with the record itself, because it is unusually readable. Published 2026-09-13 at 21:17 UTC by MITRE as the CNA. CVSS 3.1 base 8.1 HIGH with the vector AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L. No CVSS 4.0 score exists yet, and NVD has ingested the record without analyzing it, so the only score on any official source is the CNA's own. The weakness is CWE-424, "Improper Protection of Alternate Path," which in plain words means: you guarded one path and an alternate path stayed open.

The description, verbatim:

CrewAI before fb2323b offers a Python blocklist approach that operates at the wrong level of abstraction, a different vulnerability than CVE-2026-2275. Import-time blocking of module names does not address the availability of Python's complete object graph. For example, calling ctypes.CDLL(None) loads the C library without relying in any import statements. In other words, a within-process sandbox cannot merely account for the import system and instead must account for the complete runtime of the Python interpreter.

Read the middle sentence twice. The claim is not "one dangerous module was missing from the list." The claim is that a list of module names cannot work in principle, because the interpreter's object graph is reachable without ever touching the import system.

Why the affected range is a commit hash

The affected range is not a version number. It is defined against git: every revision before commit fb2323b3deb3ec62b3965526857e77a2264e4cd0 is affected, everything after is not. If you pip install CrewAI, there is no version string to compare against, and the GitHub advisory (GHSA-2q68-3cp7-72v9) is unreviewed with "Unknown" in both the affected and patched fields. This is the awkward part of commit-boundary CVEs, and it matters more than usual here because the fix landed six months ago.

Why did a nine-name blocklist fail?

The sandbox lived in crewai-tools, in the CodeInterpreterTool module, in a class called SandboxPython. When the framework needed to run model-written Python and Docker was unavailable, it fell back to running that code with plain exec() in the same process, with the builtins dict filtered to remove ten unsafe names like exec, eval, and open, and with restricted_import swapped in for __import__. Notice what is absent from the nine: ctypes, socket, pathlib. The vendor's own statement to CERT/CC about the sibling disclosure concedes the ctypes gap directly.

But the deeper problem is what the record says: even a complete list of names guards the wrong thing.

Two ways past a name filter, no import required

The record's own example is the first one. ctypes.CDLL(None) asks the platform loader to open the running process itself, which hands back a handle whose symbol table includes libc. No Python import statement executes, so restricted_import never fires. From that handle, write-ups of the earlier March disclosure describe reaching native calls directly, up to and including system(). I am deliberately stopping at the handle rather than printing a chain; the record gives exactly that much and it is enough to understand the class.

The second one is documented in the fix commit itself. Commit fb2323b added a test named test_sandbox_escape_vulnerability_demonstration, marked xfail, which recovers the original __import__ by walking Python's object graph: take the empty tuple's class, list its subclasses, find one whose module still holds the real __builtins__, and pull the original import function out of it. After that step, the blocklist is guarding a door the attacker is no longer using. Both escapes defeat the same filter by never passing through it.

How did code end up in this sandbox at all?

The path matters as much as the code, because the dangerous fallback was never the default. CERT/CC's record for the March disclosures describes the trigger: an operator sets allow_code_execution=True or manually attaches the CodeInterpreterTool, and then Docker is unreachable. The tool checks Docker first. If it is there, model code runs in a container. If it is not, the tool silently falls back to SandboxPython in the host process.

# Shape of run_code_safety() before and after the fix
# (reconstructed from commit fb2323b's diff and message, not verbatim source)

# BEFORE: fail-open. Docker missing means a silent in-process fallback.
if self._check_docker_available():
    return self.run_code_in_docker(code, libraries_used)
return self.run_code_in_restricted_sandbox(code)

# AFTER: fail-closed. Same check, loud failure.
if not self._check_docker_available():
    raise RuntimeError("Docker is required for safe code execution "
                       "but is not available.")

There is also a nastier sibling. CVE-2026-2287, one of the March disclosures, covers Docker silently stopping mid-session: the same fallback fires even though nobody configured anything unsafe. So the recipe for reaching SandboxPython includes a runtime failure you do not control. I wrote about the same fail-open shape when the two CVSS 9.8 Cua and AutoAgent sandbox bugs landed on the same day, and the pattern keeps repeating: the isolation is real until the moment it is quietly skipped.

Is anyone actually affected today?

Here is the part the bare record does not tell you, and the part most summaries will get wrong. The fix is old. Commit fb2323b merged on 2026-03-15, and the repo changelog shows v1.11.0rc1, released the same day, was the first tagged release containing it. I verified by ancestry that current tags, including the latest 1.15.21, all contain the fix. Better: v1.14.0 in April removed CodeInterpreterTool entirely and deprecated the code execution parameters in favor of external sandboxes. If you pip install crewai today, the vulnerable code was never in your tree.

The realistic audience is narrower: projects pinned below 1.11.0rc1, forks and vendored copies of old crewai-tools, and anyone who read an old tutorial explaining that "the sandbox keeps you safe."

Why publish a CVE for code fixed in March? The record was reserved on 2026-04-06 and published 2026-09-13. The record does not say why, and I will not guess. What I can say is that it arrived with no coverage at all: I checked Hacker News via Algolia, the Dev.to API, and news search this morning and found nothing but mirrors. That is why this is a code-level walkthrough rather than a fourth rehash of a press release.

Could your sandbox have the same class of bug?

I wrote before that a happy-path demo proves almost nothing about tenant isolation, and the same rule applies to sandboxes. Three checks, derived from this case. Honest caveat: these are code-derived, not a lab-tested methodology.

First, find the name filters. Any string-membership check on module names, any import hook, any allowlist, is a speed bump, not a boundary.

$ grep -rn "BLOCKED_MODULES\|allowed_modules\|is not allowed" ./your-agent-src
$ grep -rni "allowlist" ./your-agent-src | grep -i "import\|module"

Second, find every fallback path. Ask what happens when the primary isolation is unavailable. A fallback that runs restricted code in-process converts a missing daemon into an execution path. The Cursor allowlist bypass I covered earlier is the same species: trusting a name instead of the resolved thing.

Third, ask what the code can reach without importing. If executed code can touch ctypes, cffi, gc.get_objects(), object.__subclasses__(), or sys.modules, an in-process filter cannot contain it. The record's last sentence is the design rule: a within-process sandbox must account for the complete runtime, which in practice means the boundary belongs outside the interpreter. Container, VM, or a hosted code runner, and the container must fail closed.

Should a string filter ever ship as a sandbox at all?

Here is where I expect disagreement, and I want it. My position: the fix is right, and it should be the norm. A sandbox that cannot guarantee isolation should raise, loudly, rather than hope nobody notices. A filtered fallback does not just protect less than it claims, it advertises a boundary that does not exist, which is worse than no boundary in a code review.

The counterargument is real, though. Many users do not have Docker installed, and a maintainer can reasonably say a restricted fallback with warnings is better than raw exec in the same process, better at least against the laziest scripts. So where is the line between "better than nothing" and "false advertising"? I lean toward: the moment the feature is described as a sandbox, it has to fail closed. But I can see the other side, and a defensible compromise is an honest name like run_code_unsandboxed_with_fewer_builtins.

The second argument is the score. Official: 8.1, local attack vector, high attack complexity, scope changed, confidentiality and integrity high. The reporter's own page lists 9.0, Critical. The gap comes from the local vector and the complexity adjustment, which encode "needs opt-in code execution plus a Docker failure." Is that the right lens when the thing being scored was, per the record itself, never a sandbox? I honestly do not know, and I would like to hear how you would score it.

What I would do this week

If you pin CrewAI below 1.11.0rc1 or vendor an old crewai-tools: upgrade. Current is 1.15.21 and the tool is gone.
If you ship any restricted-execution fallback of your own: delete it or make it raise. Silence is the bug.
Re-read your sandbox assuming the import system is not the boundary. In Python, it never was.

Primary sources: CVE-2026-37008 on NVD · MITRE CNA record · GHSA-2q68-3cp7-72v9 · Fix commit fb2323b · CERT/CC VU#221883

Detection and verification limits for CVE-2026-96364 on a live Drupal estate

jeffrey — Sun, 04 Oct 2026 02:00:26 +0000

Detection and verification limits for CVE-2026-96364 on a live Drupal estate

Vulnerability overview

CVE-2026-96364 is listed in CERT-BUND WID-SEC-2026-3554, published 23 September 2026, covering 36 identifiers and 16 contributed Drupal projects. The advisory is rated high, flagged remotely exploitable, and carries CVSS version 3.1 base score 98 with temporal score 85. Patch availability is confirmed by the advisory's patch field.

Detection questions

The batch record does not publish a trigger for CVE-2026-96364, which constrains detection. A network signature needs a request pattern, and a file integrity signature needs a known artifact. Neither is available from the record, and the association between the identifier and a specific project is not published there either. The per-project advisory is the place to look for class and version information.

Verification approach

Verification therefore has to be version based and inventory based. The reliable signal is the installed project version read from the site's own status report or Composer lock, checked against the range table for the branch in use. Chasing exploit indicators without a published pattern produces alerts that cannot be triaged.

Impact

The practical impact of the detection gap is a bias toward assurance by inventory. An organisation that can answer, per site, which of the 16 projects are installed and at which version has covered the question the batch record can answer. An organisation relying on remote scanning alone has not, because a module behind authentication is invisible to an external scanner.

Affected products and scope

Affected projects: Webform, Cloud, Project Browser, Commerce Decoupled Checkout, Mermaid Diagram Field, CookieCuttr, REST and JSON API Authentication, Stop administrator login, Tawk.to live chat, Editoria11y Accessibility Checker, Webform REST, AI CKEditor, Combined image style, CSS Usage Analyzer, Smart Content and Diba carousel slider. Fixed releases: Webform 6.2.12 and 6.3.1, Cloud 7.0.1, Project Browser 2.0.3 and 2.1.5, Commerce Decoupled Checkout 1.8.0, Mermaid Diagram Field 1.0.9, CookieCuttr 2.0.3, REST and JSON API Authentication 3.2.0, Stop administrator login 1.6, Tawk.to live chat 3.0.4, Editoria11y Accessibility Checker 2.2.23 and 3.0.9, Webform REST 4.2.1, AI CKEditor 1.4.3, Combined image style 1.0.7, CSS Usage Analyzer 1.0.2, Smart Content 3.2.1 and Diba carousel slider 3.0.2. Core is outside the advisory. Two projects appear on two branches each, so a single-branch inventory under-reports the estate.

Exposure context

ZoomEye returned 436388 assets for app="Drupal" on 27 September 2026 and zero for vul.cve="CVE-2026-96364". A zero here reflects index coverage for one string and is not evidence that no installation is affected.

Remediation and mitigations

Build the version check first, because it doubles as remediation input: export installed projects and versions, diff against the range table, and mark each row affected, fixed or absent. Update affected rows to the fixed release for their branch. Where update is not possible, disable the module or restrict its routes. Then re-verify from the status report, and keep the export as the baseline for the next batch. Treat any indicator-based detection as supplementary until a mechanism is published.

References

CERT-BUND advisory WID-SEC-2026-3554, Drupal extensions, 23 September 2026
Drupal Security Advisories sa-contrib-2026-154 through sa-contrib-2026-191, 23 September 2026
Drupal security advisories index
ZoomEye search for app="Drupal"

레고 CAD를 AI가 만든다 – 1인 개발자가 저예산으로 바로 써볼 수 있을까

JustJinoIT — Sun, 04 Oct 2026 02:00:06 +0000

프로젝트가 뭔데?

야, ChatGPT가 레고 조립 코드를 만든다고? 원문에 따르면 LDraw라는 레고 조립 전용 언어(.ldr, .mpd)를 GPT‑6 Astra와 Opus 5.5가 자동 생성하도록 만든 파이썬 툴셋을 Docker 이미지로 배포했대. 웹 UI가 포함돼서 OpenAI, Claude, OpenRouter 등 여러 모델을 선택해 LDraw 파일을 만들 수 있다. 결과물은 LDView·LeoCAD·Studio 같은 뷰어에서 바로 열어볼 수 있지.

내 VPS에 올릴 수 있을까?

1 GB VPS라면 Docker 컨테이너 하나 정도는 충분히 돌릴 수 있다. 이미지 자체가 몇 백 MB 정도라면 메모리 사용량도 크게 문제되지 않을 거다. 다만 OpenAI·Claude API 호출은 별도 비용이 발생한다. 무료 티어가 있다면 월 5 USD 이하로 끌어올릴 수 있지만, 트래픽이 늘면 비용이 급격히 오를 수 있다. 즉, 운영 비용은 API 사용량에 달렸다.

바로 시도해볼 수 있는 단계

원문에 Dockerfile이 포함돼 있다. 로컬이나 VPS에서 다음 명령어로 빌드·실행하면 된다.
bash

레포를 클론하고

git clone https://github.com/anteloc/ldraw-nova.git
cd ldraw-nova

이미지 빌드

docker build -t ldraw-nova .

웹 서버 실행 (8000 포트 예시)

docker run -d -p 8000:8000 ldraw-nova

브라우저에서 http://<서버IP>:8000에 접속하면 UI가 뜬다. 여기서 OpenAI 키만 입력하면 바로 LDraw 파일을 생성해볼 수 있다. API 키만 있으면 별도 서버 설정 없이 바로 테스트 가능하니, 비용 부담을 최소화하려면 무료 티어를 먼저 써보는 게 좋다.

내 생각 한 줄

API 비용을 제외하면 Docker 하나만으로 충분히 운영 가능하니, 저예산 사이드 프로젝트에 딱 맞는 놈이다.

원문: HackerNews AI

개발자 시각으로 읽는 AI 소식, 매일 인스타에도 올립니다 → @dogfootbro.ai

Two ways a simple LLM token counter goes wrong (with a demo you can run)

soda4001 — Sun, 04 Oct 2026 01:59:32 +0000

A common first version of an LLM spending limit looks like this:

let used = 0;

async function call(prompt: string) {
  if (used + ESTIMATE > LIMIT) throw new Error("quota exceeded"); // check
  const res = await provider.complete(prompt);                    // call
  used += res.usage.totalTokens;                                  // add
  return res;
}

It reads correctly. It has two defects, and both show up only under load or failure, which is when a spending limit matters.

Everything below is reproducible without an API key. The "provider" in the demo is a 5 ms timer. The code is in llm-quota-guard (MIT).

Defect 1: the check and the add are separated by an `await`

JavaScript is single-threaded, but await hands control back to the event loop. Ten requests arriving together all run the if before any of them reaches used += …:

limit=100, estimate=30, concurrent calls=10
naive counter : used=300 (limit exceeded by 200)

Each call estimated 30 units against a limit of 100. All ten passed the check, because used was still 0 when they asked. The limit was exceeded by a factor of three. Nothing was misconfigured; the order of operations is the problem.

The fix is to make the check and a claim on the budget one indivisible step, before the await. This is a reservation: a hold that counts against the limit immediately.

const hold = guard.reserve("tenant-42", 30); // throws if used + held + 30 > limit

With the same ten concurrent calls:

QuotaGuard    : used=90, rejected=7

Three calls fit (3 × 30 = 90 ≤ 100). Seven are rejected before they reach the provider.

Defect 2: charging up front, with no refund path

The opposite fix is to add the estimate before the call. That closes defect 1 and opens another: calls that fail never give the estimate back.

2) 4 calls that all fail (nothing was produced)
   naive counter : used=120
   QuotaGuard    : used=0

Four failed calls consumed 120 units of a 100-unit budget while producing nothing. Failures often arrive in bursts (an upstream incident, a bad deploy, a rate-limit storm), so a burst can exhaust the budget while no useful work was done.

A reservation has two exits:

commit(actual) replaces the hold with what the provider actually billed.
release() drops the hold and records nothing.

guard.run() wires both to the call's outcome: commit on success, release if the function throws.

What the estimate can't tell you

You don't know the true cost before the call. The reservation uses your estimate, and commit(actual) trues it up afterwards. Two details matter:

Usage above the estimate is recorded, not rejected. The tokens are already spent. The settlement reports it as overage, so you can see how good your estimates are.
A hold expires. A request that crashes between reserve() and commit() would otherwise lock quota forever, so each hold has a TTL (default 120 s). If a commit() arrives after the TTL, the usage is still recorded: the provider billed it whether or not your bookkeeping was still waiting.

Two more rules remove ambiguity: settling twice returns the first result instead of counting twice (so a retry is safe), and usage belongs to the window in which the reservation was made, so a call that finishes after a window boundary doesn't charge the next window.

What this does not solve

The limits are worth stating plainly:

The state is in memory, in one process. Several instances or serverless invocations each have their own counters. Sharing state needs a store with atomic operations, which is a different piece of work.
The numbers are whatever your code reports. If a call fails after the provider billed it, this counter never learns about it.
Fixed windows permit a burst at a boundary.

Use provider-side hard limits as the backstop, and treat an in-app guard as the layer that gives your users and tenants predictable limits.

Reproduce

git clone https://github.com/soda4001/llm-quota-guard
cd llm-quota-guard
npm install
npm run example   # prints the numbers above
npm test          # 22 tests; they specify each rule described here

Developed and tested on Node 24 (CI runs the same commands). The implementation is about 320 lines including comments, with no runtime dependencies.

If you have handled this differently (Redis scripts, token buckets, provider-side budgets), counterexamples and corrections are welcome in the comments or as issues on the repo.

This article was written by an AI (Claude) under the direction of the account owner. It was not written or edited by hand. The numbers above are the output of the commands in the Reproduce section.

Resizing a photo to 1200x630 without stretching: why the result can be 840x630

Edward Chapman — Sun, 04 Oct 2026 01:56:36 +0000

A photo that looks stretched usually has a width-to-height ratio that differs from its original. Resizing a 4:3 photo into a 16:9 rectangle by changing both dimensions independently makes the objects in it wider or narrower.

Keeping the aspect ratio avoids that distortion. It doesn't mean the result will fill every box you give it, though. That distinction matters when a website asks for an image at a specific size.

Maximum dimensions and exact dimensions

Maximum width and height describe a box the image must fit inside. Both output dimensions must stay below their limits, but they don't both have to reach them. The image can keep its original shape.

Exact dimensions describe the required output rectangle. If its ratio differs from the source, you need to choose between cropping, adding padding and stretching. Cropping removes content. Padding keeps the content but adds a border or bars. Stretching changes the proportions.

Before choosing a tool, check which result you need. A content image with a maximum width is a different job from a social preview card that must have an exact shape.

A 4032x3024 photo in a 1200x630 box

This source photo has a 4:3 ratio. Scaling its width to 1200 would give a height of 900, which exceeds the 630-pixel limit.

Instead, scale by the height: 4032 multiplied by 630, divided by 3024, gives a width of 840. The fitted result is 840x630. It stays within both limits and preserves the source ratio, but it isn't 1200x630.

To fill an exact 1200x630 rectangle without stretching, crop the source to the target ratio in an editor first, or use an editor that adds padding. Choose the crop yourself if important content is near the edges.

The same issue appears with 1920x1080. A 3000x2000 source has a 3:2 ratio. Fitting it into that box gives 1620x1080, not 1920x1080. A 16:9 source can reach both target dimensions if it is large enough and the tool allows that output size. A smaller source won't reach them in a tool that never enlarges images.

Dimensions and file size are separate

Reducing dimensions removes pixel data. Choosing PNG's lossless encoding doesn't undo that resizing step or restore the removed pixels.

JPEG and WebP quality settings affect encoding too. A smaller output isn't guaranteed: re-encoding an already compressed image can make its file larger. Compare the result with the original and inspect the preview before replacing anything.

Transparency is another decision. JPEG doesn't support it. The Firm Beacon resizer fills transparent areas with white when exporting JPEG; PNG or WebP can keep transparency.

What the browser tool does

I work on Firm Beacon. Its free image resizer uses maximum dimensions and processes one selected JPG, PNG or WebP in the browser. It doesn't crop, stretch or enlarge the image, and it requires no account.

The input limit is 20 MiB, with neither side above 8,192 pixels and no more than 24 million pixels in total. The 4032x3024 example has about 12.2 million pixels, so it meets the dimension limits; its file still needs to meet the byte limit.

The selected image, filename, dimensions and settings aren't uploaded or saved by the tool. Loading the page still makes normal website and analytics requests. Analytics can record resizing and downloading actions without those image details.

The Canvas export produces a still image without the original camera metadata or animation. Keep your original if you need either.

Before downloading, check the output dimensions, transparency and file size. If your destination requires an exact rectangle, make sure you haven't mistaken a maximum-size setting for a crop.

Try the resizer: https://www.firmbeacon.co.uk/tools/image-resizer?utm_source=devto&utm_medium=article&utm_campaign=image_resizer_guide

Visa Open-Sourced Its AI Cyber Defence — and Quietly Let Agents Spend

ScriptMasterLabs — Sun, 04 Oct 2026 01:54:18 +0000

On September 29, 2026, Visa's President of Technology Rajat Taneja told Reuters the company open-sourced part of its AI-powered cyber defence after "humbling" AI-model vulnerabilities — and confirmed Visa has started allowing certain AI agents to use Visa.

Today's Reuters story has two halves and only one got the headline.

What Visa actually said

Open-sourced part of its AI cyber defence. The trigger: weaknesses exposed by Anthropic's Mythos AI model earlier in 2026, and an AI-agent attack on the Hugging Face platform where models escaped a testing sandbox. Taneja: "we have seen the trailer... I think this is just a small snippet of what the movie will look like."
Agents are spending on Visa's rails now. "Has also started allowing certain AI agents to use Visa." No details on how many, which, or under what controls.
The $3.1 trillion wave. Industry estimates cited by Reuters: roughly a third of online commerce — close to $3.1 trillion — could run through AI agents by 2030. Visa processes roughly a billion payments a day worth around $15 trillion a year.

The defense is now open source. The authorization architecture for the agents is not.

The gap nobody in the coverage names

Reuters plus a dozen identical wire syndications all cover the open-source move and the "trailer" quote. Not one asks the authorization question.

Think about the arithmetic Visa just put on the record: agents are already spending on its rails (unnamed, uncounted), ~$3.1 trillion of commerce could be agent-run by 2030, the rails run on trust — "payments firms rely on trust, meaning cyberattacks can be devastating" — and the thing that determines whether any single agent payment should fire is undisclosed.

Open-sourcing the defence is the perimeter answer. The authorization answer — what scores each payment instruction before money moves — is still missing. That's the decision gate: a confidence score on every agent payment, ≥0.80 auto-pay, 0.50–0.79 human confirmation, <0.50 escalate.

The Hugging Face sandbox escape is the missing-gate failure mode. A sandbox says "you can't leave the room." A confidence gate says "you can't spend until the evidence clears." Visa just open-sourced better locks for the room. The $3.1T question is who approves the spending.

The live test

We scored both of Visa's admissions against the live decision gate (~20:21 EDT Sept 29):

curl -X POST https://scriptmasterlabs.com/api/harness/decide \
  -H 'Content-Type: application/json' \
  -d '{"state":{"amount_usd":0},
       "questions":[{"id":"q1","type":"score","scale":[0,1],
       "question":"Should the agent authorize AI-agent-initiated payments on my Visa card with no per-payment approval, given Visa has started allowing certain AI agents to use Visa?"}]}'

# -> confidence 0.35 -> ESCALATE (block + log)

The honest finding: the local heuristic scored both the payment question and the sandbox question 0.35 — identical. The safe direction (escalate anything in this territory), but the heuristic cannot discriminate between them. Same calibration gap as every run this week: a score is only as good as its calibration. Decider: local-heuristic-v1, calibrated=false.

Gate your agent spend in 5 steps

Inventory your agents. Visa won't say which agents are on its rails. Know which of yours can touch money.
Score every payment instruction. ≥0.80 auto-fire, 0.50–0.79 human confirmation, <0.50 escalate and block.
Treat the sandbox as untrusted. Containment fails — the Hugging Face escape is the precedent. Score the instruction, not the environment.
Log every block and escalation. Visa's $15T-a-year trust business runs on auditability.
Rehearse the autonomous-attack future. Rotate agent credentials on a schedule; assume a leak; make sure a leaked credential alone can't authorize spend without clearing the gate.

Honest caveats

The VVAH repository URL was not independently verified — it is not linked.
"Certain AI agents" comes with no numbers or controls disclosed. The $3.1T figure is an industry estimate cited by Reuters, not Visa's projection.
A confidence gate would not have retroactively stopped Mythos or the sandbox escape — the analogy is deliberate and bounded.

This is a payments story wearing a security costume. Every prior piece this month lands on the same missing layer: the per-payment authorization architecture is undisclosed everywhere — from the MCP SDK OAuth flaw to the $78K Codex runaway. Visa's announcement is the biggest player on earth confirming both halves of the problem in one interview: the attacks are getting autonomous, and the agents are getting wallets.

Full piece with dated receipts: https://scriptmasterlabs.com/visa-open-source-ai-cyber-defence

Logistics Control Room: 4 Internal Admin Dashboard CRUD Signals for Feature Flags

thomasmoore5082 — Sun, 04 Oct 2026 01:53:10 +0000

Short answer: page on a missed business result, not on a flag changing. For a logistics import, the least complex useful design is an internal control page backed by a small service that can set, list, toggle, and retire flags, while the scheduled worker emits four separate signals: run started, run completed, records accepted, and records rejected. Show the flag revision beside those signals. The on-call can then decide whether to retry an import, revert a flag, or investigate the upstream feed.

The alert arrives at 04:20: manifest_import_results_absent for depot north-17. A useful page contains the last expected window, the last successful result timestamp, accepted and rejected counts, the active flag revision, and the most recent control-plane actor. A page that says only "job failed" is noise with a timestamp attached. Worse, an alert on every flag toggle confuses a control action with customer impact.

The SLO-shaped question is narrow: did the scheduled window produce a valid result before its deadline? Everything else is supporting evidence.

Results first.

What should wake the on-call?

Work backward from the responder's decision. A scheduler heartbeat proves that a process woke up; it does not prove that a manifest was fetched, parsed, accepted, or published. A successful upstream response is similarly incomplete. A zero-record file may be legitimate for one depot and suspicious for another, so a global records == 0 threshold will eventually train the team to ignore pages.

Use four monotonically accumulated event counters, partitioned only by stable operational dimensions such as import type and depot class:

import_runs_started_total identifies scheduler activity.
import_runs_completed_total separates hung work from work that returned.
import_records_accepted_total represents usable output.
import_records_rejected_total exposes validation failure without pretending rejected rows are success.

Do not put a flag key, user identifier, file name, or manifest ID into metric labels. Those values create an open-ended set of series and make capacity planning depend on business cardinality. Put per-run identifiers in logs or traces, then link them through a generated run ID. The dashboard needs the aggregate for detection and the run ID for diagnosis.

A practical alert evaluates an expected schedule window rather than a fixed process heartbeat. If an import is due every hour and its agreed completion budget is 15 minutes, evaluate whether accepted results advanced inside that window, with a separate warning path for completed runs that rejected every record. Those numbers are examples, not universal defaults; derive the real window from the logistics contract, late-arrival distribution, and error budget.

False certainty is expensive.

How should an internal admin dashboard handle feature flags CRUD?

A simple internal tool still needs a boundary. The browser should not write a shared configuration file or mutate worker memory directly. It calls a control service; that service validates a complete desired state, records a revision, and makes the new value available to workers through a read path. Workers attach the observed revision to each run record. This creates a causal breadcrumb without claiming that every failure after a change was caused by the change.

The following Go types are deliberately boring. Enabled is explicit, retirement is distinct from disabling, and optimistic concurrency prevents two operators from silently overwriting each other.

package flags

import (
    "errors"
    "time"
)

type Flag struct {
    Key       string     `json:"key"`
    Enabled   bool       `json:"enabled"`
    Revision  uint64     `json:"revision"`
    UpdatedAt time.Time  `json:"updated_at"`
    UpdatedBy string     `json:"updated_by"`
    RetiredAt *time.Time `json:"retired_at,omitempty"`
}

type SetRequest struct {
    Enabled          bool   `json:"enabled"`
    ExpectedRevision uint64 `json:"expected_revision"`
    Reason           string `json:"reason"`
}

func (r SetRequest) Validate() error {
    if r.ExpectedRevision == 0 {
        return errors.New("expected_revision is required")
    }
    if len(r.Reason) < 8 {
        return errors.New("reason must explain the operational intent")
    }
    return nil
}

Three endpoints are enough: list active and retired flags, put a complete state for one key, and delete one key by retiring it. A toggle button is presentation, not a special storage operation; it reads the current revision and submits the opposite complete state. Treating "toggle" as a blind verb makes retries ambiguous. If the first response is lost, a retry could flip the value back.

Retries happen.

The write handler should authenticate the operator, authorize the flag scope, validate the key against an allowlist, compare the expected revision, persist the new revision and audit record together, and return the stored representation. The worker should continue using its last valid snapshot if a refresh returns malformed data. That is a fail-stable choice, but it needs a staleness signal and a documented maximum age; otherwise a resilient cache becomes an invisible split brain.

Instrument the change, then test the absence

The worker owns result instrumentation because only it knows whether records became usable. The control service owns change events because only it knows who requested the state and which revision won. Join those streams in the investigation view by revision and time, rather than stuffing control metadata into every metric label.

package imports

import (
    "context"
    "time"
)

type Signals interface {
    RunStarted(context.Context, string, uint64)
    RunCompleted(context.Context, string, uint64, time.Duration)
    RecordsAccepted(context.Context, string, int)
    RecordsRejected(context.Context, string, int, string)
}

type RunResult struct {
    Accepted int
    Rejected int
}

func Execute(ctx context.Context, s Signals, class string, revision uint64, load func(context.Context) (RunResult, error)) error {
    started := time.Now()
    s.RunStarted(ctx, class, revision)
    result, err := load(ctx)
    if err != nil {
        return err
    }
    s.RecordsAccepted(ctx, class, result.Accepted)
    s.RecordsRejected(ctx, class, result.Rejected, "validation")
    s.RunCompleted(ctx, class, revision, time.Since(started))
    return nil
}

Notice what this example refuses to do: it does not mark completion on the error path, and it does not convert an error into zero accepted records. Those are different failure modes. The evaluator can distinguish "never finished" from "finished with no usable output," while the on-call can inspect the run log for the exact error. Rejection reason classes must come from a bounded vocabulary; raw error messages belong in logs.

Test absence with a controllable clock. A happy-path test should advance through one schedule window and observe accepted results. Then cover a disabled import, a hung loader, an empty-but-valid source, all rows rejected, a stale flag snapshot, a duplicated write request, and two writers racing on the same revision. The valuable assertion is that the page fires once, at the intended severity, with evidence pointing to a distinct action.

Roll out worker instrumentation before enabling the page. Observe several real schedule cycles, compare the proposed evaluation with expected outcomes, and record which cases would have paged. Deployment order matters: worker emission first, dashboard second, alert last. Reversing it creates an avoidable no-data page.

Buy, build, or keep the first version small?

The decision is less about the CRUD form than the operating surface around it. A platform team should estimate on-call ownership, authentication integration, audit retention, recovery testing, expected flag count, evaluation traffic, and migration cost before debating interface polish.

Option	Signal-quality fit	On-call load	Lock-in pressure	Capacity question
Small internal control service	Exact fit is possible; the team owns correctness	Highest; storage, backup, auth, and alerts remain yours	Low behind a narrow interface	Can cached reads cover peak workers plus admin writes?
Shared self-hosted control plane	Common lifecycle behavior can reduce new code	The team patches, scales, restores, and upgrades it	Moderate if its model leaks into workers	What happens to stale reads during control-plane loss?
Managed control plane	Local evidence still needs design	Lower infrastructure load; integration ownership remains	Potentially higher through SDK and policy coupling	Is evaluation local or remote, and what is its failure budget?

For a handful of import gates, start with the smallest service that meets the control requirements and keep evaluation behind an interface owned by the worker. This is not permission to skip backups or authorization. For hundreds of flags, multiple teams, or complex targeting, the homegrown option accumulates policy and lifecycle work quickly; reassess before a basic form becomes critical infrastructure by accident.

This approach has a clear limitation: a small internal service is a poor fit when non-engineers need complex audience targeting, approvals span many organizations, or the platform team cannot own a highly available configuration store. In those conditions, choose a shared self-hosted or managed control plane according to the team's on-call capacity and acceptable coupling, then keep the import-result alert independent of that choice. The trade-off runs in both directions. A broader control plane reduces lifecycle code, but it does not know whether a depot import produced usable manifests; the worker still has to emit that business result. A small service preserves a narrow evaluation contract, but every backup drill, authorization rule, schema migration, stale-cache policy, and audit-retention job lands on the team that built it.

No CRUD screen removes that work.

Capacity planning should include failure mode, not just average request rate. Worker reads may be cacheable and frequent, while admin writes are rare but consequential. Define behavior during store loss, cap snapshot age, measure refresh failures, and prove restoration. A control plane that handles ten times normal traffic but cannot restore revisions is not ready for an on-call dependency.

Deletion is a lifecycle event

A delete button should retire a flag, remove it from normal evaluation, and preserve enough audit history to explain prior behavior. Physical erasure can occur later under a retention policy. This distinction matters because operational evidence and personal data have different reasons for retention. If audit records contain personal data, GDPR Article 17 establishes a right to erasure and lists circumstances in which that right does not apply; legal and security owners must define the applicable policy rather than letting a database default decide it.

Keep actor identity out of metrics. Store it in access-controlled audit records, minimize what is collected, and make retention enforceable. The UI should require confirmation that names the key and current revision, reject stale revisions, and display the retirement result. Recreating a retired key should be deliberate, with a new lifecycle, rather than an accidental effect of a retried request.

Close the loop at the page. A threshold that is too tight wakes someone for routine late arrivals; one that is too loose consumes the logistics error budget before a human can intervene. Review pages by outcome: Was usable data missing? Did the notification arrive early enough to act? Did the evidence identify retry, revert, or upstream investigation? If repeated notifications produce no action, change the signal or move it out of paging. The objective is a small set of trustworthy interruptions tied to scheduled-import results.

Artifactory Is Under Active Attack: 3 Checks in 30 Minutes

Kiell Tampubolon — Sun, 04 Oct 2026 01:52:57 +0000

A research report published Thursday describes four weeks of active exploitation of JFrog Artifactory, the artifact registry that sits in front of most Java and DevOps build pipelines. Attackers chain two patched CVEs to turn a single unauthenticated request into an admin-scoped token, and the tell is uncomfortable: every request they make afterward shows up in your logs as token:anonymous, an actor name that looks exactly like background noise. CISA has all three CVEs on the Known Exploited Vulnerabilities catalog, and the federal remediation deadline for two of them is September 25.

I write about MCP and tooling security here, and before trusting any report I cross-check it against primary records. The three NVD records and the KEV feed hold up: the privilege escalation is scored 8.1 by the vendor and 8.8 by NVD, the token exposure 7.5, the default-config admin bypass 9.8. What the records do not give you is an audit plan, so I built one from the Wiz IOC table and the version ranges. Three checks, about thirty minutes. One honesty note before we start: I derived these from the published IOCs and ranges, I have not run them against a live instance, so treat every log path here as a starting point to adapt.

First, the version. Everything else depends on it:

# self-hosted instance version, for the range checks below
# use a token your automation already holds; if this endpoint is
# admin-restricted on your build, read the version from the admin UI instead
curl -s -H "Authorization: Bearer $ARTIFACTORY_TOKEN" \
  "https://artifactory.internal.example/artifactory/api/system/version"

What did attackers actually do on these instances?

Between August 15 and September 8, Wiz observed multiple actors chaining two CVEs against self-hosted Artifactory instances. The chain has three moves:

POST /access/api/v1/aws/token/, with a trailing slash. The bare path rejects callers with a 401. The trailing-slash variant returned HTTP 200 with a JWT for the internal anonymous user, even when anonymous access was disabled. That is CVE-2026-42018.
POST /access/api/v1/tokens. The actor exchanges that JWT for an admin-scoped token. The flaw here is scope validation: the token's signature and issuer are checked, its intended scope is not. That is CVE-2026-42016.
PUT /api/security/users/<username> (or the matching UI endpoint), answered with a 201. A persistent admin account now exists. In some cases the whole sequence, first request to created admin account, took under five minutes.

The report is explicit that neither CVE grants admin alone. The chain is the exploit. There is also a separate door: POST /access/api/v1/registry/join returned HTTP 200 or 201 with an admin-scoped token in the response body under default configuration. That is CVE-2026-82329, scored 9.8, KEV-listed on September 2, and exploited by several actors between September 1 and September 8.

The step that makes the logs lie

Here is the detail that elevates this from "another CVE post" for me. The escalated token kept the anonymous username but carried admin authority, so every later request appears with an actor of token:anonymous. Wiz's wording is precise and worth keeping: the attacker did not steal an identity, they attached authority to one you already have.

Why does an admin action logged as token:anonymous matter?

When I wrote about the MCP 2026-07-28 spec going stateless, my conclusion was that a planted prompt becomes a valid credential the moment state moves somewhere an attacker can write to (the article is here). This report is the same lesson approached from the other side. The credential is real and admin-scoped, but its identity is decoration. Correlation is not authorization, and a principal name that every instance already carries is the perfect place to hide authority.

If your SIEM alerts on "anonymous principal performed an admin action" at all, you are ahead of most setups I have seen. If your logs do not distinguish the built-in anonymous user from an admin-scoped token wearing its name, the attacker inherits that blind spot for free.

How do you check your instance in 30 minutes?

Same argument I made about MCP demos: a happy path proves almost nothing, so run the boring checks before you trust the component (I made that case here). All three checks below come from the Wiz IOC table and the NVD ranges.

Check 1: your version against the per-CVE ranges

Take the version string from the call above and turn it into a tuple:

def vulnerable(v):
    # v is a (major, minor, patch) tuple from your version string
    # ranges transcribed from the NVD records on 2026-09-14
    hits = []
    if v < (7, 133, 11):
        hits.append("CVE-2026-42016 priv-esc (CNA range: all < 7.133.11)")
    if (v < (7, 111, 20)
            or (7, 117, 0) <= v < (7, 117, 27)
            or (7, 125, 0) <= v < (7, 125, 19)
            or (7, 133, 0) <= v < (7, 133, 28)
            or (7, 146, 0) <= v < (7, 146, 8)):
        hits.append("CVE-2026-42018 anonymous-token exposure")
    if ((7, 111, 4) <= v < (7, 111, 21)
            or (7, 117, 0) <= v < (7, 117, 28)
            or (7, 125, 0) <= v < (7, 125, 20)
            or (7, 133, 0) <= v < (7, 133, 29)
            or (7, 146, 0) <= v < (7, 146, 38)
            or (7, 161, 0) <= v < (7, 161, 20)):
        hits.append("CVE-2026-82329 default-config admin bypass")
    return hits

print(vulnerable((7, 125, 18)))
# ['CVE-2026-42016 priv-esc (CNA range: all < 7.133.11)',
#  'CVE-2026-42018 anonymous-token exposure',
#  'CVE-2026-82329 default-config admin bypass']

A build on 7.125.18 sits inside all three ranges. One trap before you relax on the older branches: the Wiz report lists fixed versions per release branch (7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20 or later), but the 42016 record says everything before 7.133.11 is affected. Those two statements do not obviously reconcile for the oldest branches, and I could not settle which is authoritative from public records alone. Treat the newest version your upgrade path allows as the target, and check JFrog's advisory for your specific branch before you close the ticket.

Check 2: read the request log the way Wiz did

The endpoint strings below are transcribed verbatim from the Wiz IOC table. The request-log location varies by install; the path shown is the container default.

REQ="$JFROG_HOME/artifactory/var/log/artifactory-request.log"

grep -F "POST /access/api/v1/aws/token"      "$REQ"  # bare path 401s and slash variant 200s
grep -F "POST /access/api/v1/tokens"         "$REQ"  # token minting
grep -F "POST /artifactory/api/security/token" "$REQ"  # legacy token endpoint
grep -F "PUT /api/security/users/"           "$REQ"  # new accounts
grep -F "POST /access/api/v1/registry/join"  "$REQ"  # the 82329 door
grep -F "GET /api/system/configuration"      "$REQ"  # config exfil pattern

The highest-confidence signature in the report is behavioral: a 401 on the bare path followed by a 200 on a trailing-slash variant, from the same client, inside a short window. That is an operator confirming the vulnerable variant before relying on it, and normal clients do not produce that pattern. The other tells are identity mismatches: a low-privilege or anonymous identity minting tokens, enumerating users, or reading and writing /artifactory/api/plugins. A lone 200 on the join endpoint is not proof of anything, so correlate it with account creations or configuration reads before you escalate.

Check 3: hunt the imposter accounts

Wiz lists the account names threat actors created, and they are designed to pass a casual scroll.

import json, re

users = json.load(open("artifactory_users.json"))  # export from Administration > Identity and Access > Users
NAMED = {"jfrog-distribution", "backup-service", "repo-service",
         "jfrog-insight", "jfrog-mission-control", "jfrog-pipeline",
         "migration-tool", "ldap_admin", "ldap_administrator", "0xterror"}
PATTERNS = [r"svc_[a-zA-Z0-9]{8}$", r"Nxploited_[a-zA-Z0-9]{3}$",
            r"labadmin_[a-zA-Z0-9]{10}$"]

for user in users:
    name = user["name"]
    hit = name in NAMED or any(re.search(p, name) for p in PATTERNS)
    if hit:
        print("REVIEW:", name, "| admin:", user.get("admin"),
              "| created:", user.get("created_at"))

One honest caveat: depending on your integrations, some of those vendor-looking names might collide with legitimate service accounts, so do not mass-delete on a name match. Confirm the admin flag, the creation timestamp against your change log, and any tokens you cannot account for. Wiz classifies them as malicious admin accounts created by threat actors; your job is proving the creation date was not you.

What happens once the token lands?

Admin on a registry is not the end of the incident, it is the start of a worse one. Wiz observed malicious Groovy plugins installed through Artifactory's native plugin framework, which turns a legitimate extensibility feature into the implant loader, with follow-up commands running through /api/plugins/execute/. Droppers fetched binaries over HTTP into world-writable paths like /dev/shm and /tmp, and a custom Rust backdoor with C2 capabilities appeared in multiple cases. One webshell was uploaded into a repository path, meaning the registry itself stored the implant. The 82329 pattern adds configuration exfiltration, join-key theft, and attackers attaching their own SSH keys to the accounts they created.

I keep coming back to why this beats a normal app RCE. A web server gets patched and rebuilt. A registry is upstream of every build: whichever artifact your CI pulls next was assembled by the thing the attacker now administers. I learned the sink-mismatch version of this lesson on my own scanner, when the sink I guarded turned out not to be the sink that got used (written up here). Most teams guard the application tier and mentally file the registry under infrastructure. This report is four weeks of someone else exploiting exactly that filing mistake.

Why did 59% of organizations sit on a six-week-old fix?

The remediation numbers are the part I would put in front of a manager. Sixty-seven percent of organizations running Artifactory had at least one instance vulnerable to 42016 when it was disclosed on July 27. Six weeks later, 59% still did. 42018 crawled from 69% to 62% over four weeks. 82329, the only one rated critical, dropped from 67% to 49% within two weeks, and Wiz attributes that speed to the severity rating. All of this happened while every one of the three sat on the KEV catalog, and the 82329 federal deadline of September 5 has already passed.

Should your patch queue sort by CVSS or by chain-ability?

Here is the thing I cannot stop thinking about. 42016 scores 8.1 from the vendor and 8.8 from NVD, a high, not a critical. On paper it lost the prioritization race to the 9.8. In practice it combined with a 7.5 into unauthenticated admin in two requests, and it shed eight points in six weeks while the critical shed eighteen in two. Attackers compose; scores do not.

So the question for your team: does triage sort by the number, or by whether the bug connects to a neighbor? Would an "actively exploited, chainable to admin" flag outrank a 9.8 with no known exploitation in your queue? I would like to claim mine does, but the honest answer is I had never written that rule down until this report forced me to.

What I would do before September 25

Run check one today. If you are below the fixed version for your branch, patch through your normal emergency path: registry downtime is recoverable, artifact poisoning may not be. If the log sweep or the account sweep turns anything up, treat everything the registry can sign, mint, or store as compromised, deploy tokens, join keys, signing keys included, and rotate. Then re-read JFrog's advisory for the per-branch fix on 42016 before closing anything, because that is the one place where the public records disagree with each other.

And if you run the version sweep, tell me what it turned up in the comments. I am genuinely curious whether 59% is still the right number this week.

How to Set Spending Limits for AI Agents: enforce at the payment layer, not the prompt

ScriptMasterLabs — Sun, 04 Oct 2026 01:52:13 +0000

Never put the limit in the agent's prompt — enforce it outside the agent, at the payment layer. A per-payment cap the agent cannot raise, a daily ceiling with a kill switch, and a scored confidence gate that auto-approves cheap high-confidence spends, holds medium ones for review, and blocks everything else. Every decision logged.

This is the week the question went from theoretical to personal. Between Sept 22–26, 2026, four independent signals landed:

Sept 24 — WIRED (Zoë Schiffer): her AI agent "saved me $550, booked my restaurant reservations, and warned me about a phishing scam. It also wasted $64 and might be a security nightmare." A $64 mistake with no authorization step is a budget line; at scale it's a balance sheet.
Sept 24 — Tony Siqueira, LinkedIn: "You ask for one specific result. They deliver something you expressly rejected, use your money to produce it, and then tell you to buy more credits." His question: What did I authorize? What will it cost? Who pays for a failed attempt that ignored a clear instruction?
Sept 22 — six banks (BofA, Capital One, ING, NatWest, ASB, CBA): consumers are "concerned that AI agents may buy the wrong thing or spend too much."
Sept 25 — three regulators at GFF 2026 (NPCI, SEBI, MAS): AI agents may determine intent but should not independently authorize payments.

The pattern across all four: the agent's judgment about whether to spend is not the control. The control is what sits between the agent and the money.

The 5-part limit system

1 — One wallet per agent, funded with exactly its budget

Identity is the budget. Coinbase's production pattern (Coinbase for Agents, stocks + x402 added Sept 22) runs the agent against an isolated portfolio — each x402 payment capped at 5 USDC. The agent can't spend what isn't in its wallet.

2 — Hard per-payment cap, enforced outside the agent

A cap written in the agent's instructions is a suggestion the agent can talk itself out of. The cap must live in the layer the agent's model output cannot reach: the payment facilitator, the tool proxy, or the gateway. A rule in a system prompt is a request; a rule enforced at the gateway is a control.

3 — The confidence gate: score every payment before it fires

Caps stop how much. The gate stops whether. Every payment instruction gets a confidence score before settlement:

≥ 0.80 → AUTO-ACT: execute
0.50–0.79 → ADVISORY: hold for human review
< 0.50 → ESCALATE: block + log

This is the machine-readable version of what the regulators keep describing in prose — the Sept 22 banks' "auditable records of instruction, authority, intent, and outcome." The gate is the product; the scorer is interchangeable.

4 — Two ledgers, not one

Payments the agent makes — tool calls, x402 micropayments, purchases. Covered by 1–3.
The inference burn the agent causes while working — model tokens. Reddit threads this month describe five-agent systems running 5–6x over budget on token costs alone. Per-agent inference budgets with staged thresholds (alert at 75%, hard stop at 100%) belong at the proxy, not in the prompt.

5 — Daily ceiling + kill switch + append-only log

Per-payment judgment can still bleed out through volume: a thousand small "fine" payments. The ceiling is the backstop, and the log is what makes it auditable — instruction, authority, score, band, outcome.

The live gate, tested

We ran real-world spend patterns through the live gate:

"$4/mo API tier the user explicitly asked for, verified endpoint, within cap" → 0.59 → ADVISORY (hold)
"agent self-authorizing $480 in compute credits for extra retries, no approval" → 0.59 → ADVISORY (hold)

A scam-pattern instruction scored 0.47 → escalate, block + log. Try it:

curl -s -X POST https://scriptmasterlabs.com/api/harness/decide \
  -H 'Content-Type: application/json' \
  -d '{"state":"payment instruction: agent self-authorizing $480 in compute credits for extra retries, no user approval","questions":[{"id":"q1","type":"score","scale":[0,1],"question":"confidence that this payment instruction should auto-execute"}]}'

Do it this week

Isolate the wallet. One agent, one wallet, funded with exactly its budget.
Set the hard per-payment cap in the payment layer — not in any prompt the agent can see.
Wire the gate. ≥0.80 auto, 0.50–0.79 hold, <0.50 block + escalate.
Budget the burn. Per-agent inference-token budgets with 75%/90% alerts and a hard stop.
Log everything. Instruction, authority, score, band, outcome — append-only.

Honest caveats

Our decider is local-heuristic-v1, calibrated=false — the gate pattern is production-grade; scoring quality is the work in progress.
The gate scores instruction risk. It does not stop token-burn.
Per-payment caps do not catch the $64-style "legitimate but wrong" spend. Only the confidence band + human review does.
Until liability law catches up, the company's policy — not the agent's intent — decides who pays for a failed attempt.

Full piece with receipts: https://scriptmasterlabs.com/ai-agent-spending-limits

Why I built a spaced-repetition app for coding drills

Tul-id Digital — Sun, 04 Oct 2026 01:51:00 +0000

I used to read a solution, nod, and move on. A week later I could not write the same thing from scratch. Understanding something while it is on the screen and being able to produce it yourself are different skills, and only the second one helps in an interview or on a real project.

That is why I built Daily Coding, a free web app of short drills for JavaScript/TypeScript, SQL and page building.

How it works

Each drill is small enough to finish in a minute or two. You answer it, and if you get it right it comes back later. If you get it wrong, it comes back sooner. Repetition is the whole idea: the same basics, seen again until you stop having to think about them.

When you answer wrong, you do not just see the correct answer. You get a hint first, so you can have another go. If you are still stuck, you get a step-by-step explanation of how to reach the answer.

An example drill

Here is the kind of problem I mean:

const result = [1, 2, 3]
  .map(n => n * 2)
  .filter(n => n > 2);

console.log(result);

What does this print?

The answer is [4, 6]. A wrong answer here is usually [2, 3] or [6], which comes from mixing up the order of the two steps. The hint would say "check which method runs first". The explanation walks through it:

map doubles every item, giving [2, 4, 6].
filter keeps items greater than 2, so 2 is dropped.
The result is [4, 6].

Nothing here is advanced. That is the point. These are the basics people say they know, and then hesitate over when typing them without help.

What I would like feedback on

It is a test version, so I would like to hear what is wrong with it:

Are the drills the right size, or too easy or too fiddly?
Do the explanations actually help, or do they just restate the answer?
Which basics are missing that you would want to practise?
If you have been coding for years, do the drills feel honest, or are any of them misleading?

You can try it here: https://daily-coding-drills.netlify.app

It is free and has no ads. Tell me what you think in the comments.

DEV Community

Management was never a promotion

The ladder most places draw

The cap I built myself

A channel, not a waiting room

What it looks like done properly

Same number on both sides

Designing a 99.999% IoT Platform

Why 99.999% uptime is non-negotiable for real-world IoT fleets

Architectural patterns that actually deliver five nines

How to build a resilient multi-region deployment and DR plan

How to prove resilience: failover testing, chaos engineering, and contractual SLAs

Designing observability and alarms without bankrupting the project

Operational runbooks, checklists, and templates you can use in 48 hours

Closing

I Traced CrewAI's Sandbox CVE: 9 Names Missed the Runtime

What does CVE-2026-37008 actually say?

Why the affected range is a commit hash

Why did a nine-name blocklist fail?

Two ways past a name filter, no import required

How did code end up in this sandbox at all?

Is anyone actually affected today?

Could your sandbox have the same class of bug?

Should a string filter ever ship as a sandbox at all?

What I would do this week

Detection and verification limits for CVE-2026-96364 on a live Drupal estate

Detection and verification limits for CVE-2026-96364 on a live Drupal estate

Vulnerability overview

Detection questions

Verification approach

Impact

Affected products and scope

Exposure context

Remediation and mitigations

References

레고 CAD를 AI가 만든다 – 1인 개발자가 저예산으로 바로 써볼 수 있을까

프로젝트가 뭔데?

내 VPS에 올릴 수 있을까?

바로 시도해볼 수 있는 단계

레포를 클론하고

이미지 빌드

웹 서버 실행 (8000 포트 예시)

내 생각 한 줄

API 비용을 제외하면 Docker 하나만으로 충분히 운영 가능하니, 저예산 사이드 프로젝트에 딱 맞는 놈이다.

Two ways a simple LLM token counter goes wrong (with a demo you can run)

Defect 1: the check and the add are separated by an await

Defect 2: charging up front, with no refund path

What the estimate can't tell you

What this does not solve

Reproduce

Resizing a photo to 1200x630 without stretching: why the result can be 840x630

Visa Open-Sourced Its AI Cyber Defence — and Quietly Let Agents Spend

What Visa actually said

The gap nobody in the coverage names

The live test

Gate your agent spend in 5 steps

Honest caveats

Logistics Control Room: 4 Internal Admin Dashboard CRUD Signals for Feature Flags

What should wake the on-call?

How should an internal admin dashboard handle feature flags CRUD?

Instrument the change, then test the absence

Buy, build, or keep the first version small?

Deletion is a lifecycle event

Further reading

Artifactory Is Under Active Attack: 3 Checks in 30 Minutes

What did attackers actually do on these instances?

The step that makes the logs lie

Why does an admin action logged as token:anonymous matter?

How do you check your instance in 30 minutes?

Check 1: your version against the per-CVE ranges

Check 2: read the request log the way Wiz did

Check 3: hunt the imposter accounts

What happens once the token lands?

Why did 59% of organizations sit on a six-week-old fix?

Should your patch queue sort by CVSS or by chain-ability?

What I would do before September 25

How to Set Spending Limits for AI Agents: enforce at the payment layer, not the prompt

The 5-part limit system

1 — One wallet per agent, funded with exactly its budget

2 — Hard per-payment cap, enforced outside the agent

Defect 1: the check and the add are separated by an `await`