DEV Community: Clydara

PHP's two critical RCE fixes: the bug wasn't new, the decision was stuck

Clydara — Thu, 22 Oct 2026 12:31:01 +0000

On October 21, 2026 the PHP project shipped emergency releases for two critical remote-code-execution bugs in the language runtime itself. The headline most outlets chose is "AI found it". The more useful part is what the PHP Foundation says about why it took so long to fix.

What happened (facts)

Releases. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, per the php.net advisory. PHP says there are no complete mitigations: updating is the only safe choice.
The bugs. CVE-2026-109618 (out-of-memory corruption) and CVE-2026-109619 (stale global state after a fatal error). Both are rated CVSS v4.0 9.2 and can allow unauthenticated remote code execution, according to CERT-EU.
Who is affected. Per AWS's bulletin, 8.5.0-8.5.11, 8.4.0-8.4.26, 8.3.0-8.3.35 and 8.2.0-8.2.34. PHP 8.1 and older get no official release; the PHP security team published minimal source backports for 7.4 to 8.1.
Disclosure went wrong. The CVE IDs leaked on October 20, the release was pulled forward a day, a researcher firm published a proof-of-concept video, and a distributor published patched images before the embargo ended, per the PHP Foundation.

Why people care

PHP sits in WordPress, Laravel and a great many business sites. The Foundation says one of the bugs could be triggered on Apache with mod_php before any application code runs, so a perfectly written app is still exposed. Amazon Threat Intelligence reportedly saw an exploitation attempt on October 17, per Tenable. OpenAI says its GPT-5.6 Sol model helped the researchers, in its disclosure post.

What the coverage is missing

1. The bug was not new, the decision was stuck. The Foundation writes that the first signs of the out-of-memory problem were found in 2024. Several fixes existed, each with a trade-off: broken compatibility, new denial-of-service risk, or changes to many third-party extensions. The team "struggled to choose" and calls the delay "a structural failure". AI did not find a hidden bug here; it proved the impact, which forced the decision.

2. The fix is the hard part, and it is still human. The Foundation says tools find bugs faster for defenders and attackers alike, and that a person makes every call and works on every patch. Reports are rising: 15 CVEs since July 1 and more than 100 invalid or duplicate reports.

3. Your version is probably not the one you think. The risk sits in containers, base images, shared hosting and old agency builds, not only in the server you patched last.

Prediction, labeled

My read, not a fact: expect more AI-assisted disclosures to land on long-standing, "known but hard" bugs, because proof of impact is now cheap. Maintainer time and funding will matter more than detection.

What to do today

php -v                      # on the host
docker run --rm IMAGE php -v   # inside each image you ship

Confirm you are on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, then rebuild images that pin an older tag. If you run 8.1 or older, plan the upgrade; do not rely on the backport branches as a long-term answer.

Sources

PHP security advisory: https://www.php.net/archive/2026.php#2026-10-21-5
PHP Foundation post: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
OpenAI disclosure: https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/
AWS bulletin: https://aws.amazon.com/security/security-bulletins/2026-143-aws/
CERT-EU advisory: https://cert.europa.eu/publications/security-advisories/2026-018

Written with AI assistance and checked against the sources above.

GitHub's new npm package firewall only protects what you route through it

Clydara — Wed, 21 Oct 2026 10:11:25 +0000

On October 20, 2026, GitHub put a package firewall into public preview. It is a policy checkpoint between your build machines and the npm registry. The useful part is not the feature list. It is the one condition it depends on: traffic has to go through it.

What was announced

Per GitHub's changelog:

The firewall sits between endpoints such as Actions runners, coding agents and developer workstations, and the upstream package registries.
It inspects both metadata requests (package lists) and the package downloads themselves.
Admins set enterprise policy. Today's controls: a configurable cooldown period, checks against the GitHub Advisory Database for malware or vulnerability alerts, and supply-chain checks such as attestation downgrades.
A wrongly blocked package can be unblocked through an exception request.
Public preview for all GitHub Enterprise Cloud customers, including data-resident. Free in preview, metered billing like Actions at general availability.
npm only for now.

Why people care

GitHub's stated reason: more attacks run at install time, harvesting credentials on CI hosts or workstations before the package's own code ever runs. Coding agents make this sharper, because they install dependencies unattended.

What it could change

A cooldown policy means a version has to age before your machines can pull it. That gives registry maintainers and scanners time to pull a bad release first. (Prediction: this is the control most teams will notice, because it changes day-to-day install behaviour.)

What the coverage is missing

Most write-ups repeat the feature list. Two points are in GitHub's own text but easy to skip:

It only sees what is routed through it. Endpoints must be configured to use the firewall "instead of pointing directly at the upstream package registries." A laptop, runner or agent container that still talks to the registry directly is outside the policy. Runtimewire's analysis makes the same point. The rollout work is inventorying every place that runs npm install.
It covers one channel. Packages from npm, today. Binaries downloaded from release pages, install scripts or other ecosystems are not in scope. Whether that matters to you depends on your pipelines (my inference, not a GitHub claim).

Also unknown from the announcement: no GA date and no metered rates.

Practical takeaway

Before enabling anything, list every runner, agent sandbox and workstation that installs npm packages and check how it resolves the registry. Then try a cooldown on one non-critical pipeline first. Setup steps: GitHub docs.

Facts above come from GitHub's changelog; predictions and inferences are labelled.

The OVHcloud CLI release swap: why the checksum file didn't help

Clydara — Tue, 20 Oct 2026 10:15:02 +0000

On Monday, October 19, 2026, someone used a hijacked contributor account to replace the download files on five old releases of OVHcloud's command-line tool on GitHub. The source code, the tags and the build pipeline were never touched. The swapped files were live for up to 94 minutes. What makes the incident worth studying is how it was caught, and why the usual "check the checksum" advice would not have caught it.

What happened (facts)

The swap. Between 12:47 and 14:21 UTC, archives on releases v0.11.0 through v0.15.0 were replaced: macOS x86_64 and arm64, Linux x86_64 and arm64, and Windows x86_64. Those releases were originally published between April 14 and September 16. The Linux i386, Windows i386, Windows arm64 and WebAssembly builds were left alone.
The checksum file went too. On v0.15.0 the attacker also replaced checksums.txt, so the published hashes matched the new binaries.
What the files were. OVHcloud says the new builds were designed to steal secrets stored on the disk of any machine that runs them. The bad binary was a plain local go build of a later commit (October 13), not something the release pipeline produced.
How it was caught. A customer's CI job pins the SHA-256 of ovhcloud-cli_Linux_arm64.tar.gz in its own configuration. The hash changed, the job failed, and the customer opened issue #300 at 13:50 UTC. OVHcloud deleted the swapped files about half an hour later.
The fix. OVHcloud published v0.16.0 that evening as an immutable release with a signed tag. A detailed postmortem has been promised.

Who was exposed

You could have received a swapped file during the window if you:

ran the official install.sh piped into sh (the script never checked a hash),
downloaded an archive from one of the five release pages,
ran a CI step that fetched the archive by URL without a pinned hash,
ran the CLI's own upgrade command from v0.12.0 to v0.14.0 on a script or manual install.

According to The Hacker News, you were not exposed through Homebrew (the cask pinned the original SHA-256), go install, a source build, or the Docker image, which had not been rebuilt.

What the coverage mostly skips

1. A checksum file next to the binary is not a security check. checksums.txt lives in the same release, under the same write permission, as the archive it describes. Anyone who can replace the archive can replace the hash. It protects you against a corrupted download, not a tampered one. The two installs that held up, Homebrew and the customer's CI, both kept the expected hash somewhere else.

2. Turning on immutability does not fix old releases. GitHub's docs on preventing release changes say plainly that immutability "will only apply to future releases". This attack hit releases from April to September. Enabling the setting today protects your next release, not the archive people may still be pinning from last spring.

3. The report had to be public. The customer filed a public issue because, per The Hacker News, the repository had no private reporting channel. Here it helped speed, but a public issue can also tip off an attacker before the files are gone.

What is not known yet

OVHcloud has not said which files the binary reads, where it sends them, how many copies were downloaded, or how the contributor's credentials were taken. OpenSourceMalware links the account to the GlassWorm campaign and calls that link its own inference. Treat the attribution as unconfirmed.

What to do

If you installed or updated the OVHcloud CLI during the window by one of the exposed paths, treat every secret readable from that machine as exposed. Rotate them from a different machine, then install v0.16.0.

For anything you ship or download from GitHub releases, the practical takeaway is to keep the hash outside the release:

# CI: pin the expected hash in your own repo, not in the release
TOOL_URL="https://github.com/OWNER/REPO/releases/download/vX.Y.Z/tool_Linux_arm64.tar.gz"
TOOL_SHA256="<hash you recorded when you first reviewed this version>"
curl -fsSL -o tool.tar.gz "$TOOL_URL"
echo "${TOOL_SHA256}  tool.tar.gz" | sha256sum -c -   # fails the job if the file changed

# For an immutable release, also check GitHub's release attestation
gh release verify-asset vX.Y.Z ./tool.tar.gz --repo OWNER/REPO

The point is where TOOL_SHA256 lives: in your repository, reviewed once, not fetched from the same release page as the archive. That is exactly the check that failed loudly for the customer who caught this swap.

If you maintain a project that publishes binaries: enable immutable releases, publish from a draft so assets are attached before the release locks, and turn on private vulnerability reporting so the next person who notices something can tell you quietly.

Sources

OVHcloud CLI issue #300 (report and maintainer replies): https://github.com/ovh/ovhcloud-cli/issues/300
OVHcloud CLI v0.16.0 release: https://github.com/ovh/ovhcloud-cli/releases/tag/v0.16.0
GitHub Docs, Immutable releases: https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases
GitHub Docs, Preventing changes to your releases: https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/prevent-release-changes
GitHub Docs, Verifying the integrity of a release: https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/verify-release-integrity
The Hacker News (October 20, 2026): https://thehackernews.com/2026/10/hackers-hijack-five-ovhcloud-cli.html

Written with AI assistance and checked against the sources above.

OpenCode's Console breach: when a middleman holds your API keys

Clydara — Mon, 19 Oct 2026 12:35:15 +0000

OpenCode, the open-source coding agent, disclosed on October 17, 2026 that an intruder reached a legacy system on the night of October 16 and that provider API keys saved in OpenCode Console "may have been exposed". About 1.4% of Console users were affected. If you only run the open-source agent in a terminal, you are outside that group. The more useful question is what the incident says about handing a key to a middleman.

What happened (facts)

The service. Console is OpenCode's optional hosted service. A workspace can save its own OpenAI, Anthropic or Google key there, and Console uses it to call the provider so team members never see the key. This is the "bring your own key" (BYOK) pattern.
The scope. OpenCode says 1.4% of Console users were affected, all of them users with an outside provider linked. They were emailed on the morning of October 17 under the subject "Action Required: Potential provider key breach". OpenCode says anyone who got no email was not affected.
The wording. OpenCode says keys "may have been exposed". It called the incident ongoing and "related to a large-scale distillation attack". It has not said how the legacy system was reached, what it was, how many keys it held, or how many users 1.4% is.
The split. Co-founder Dax Raad wrote that the breach involves the Console, not OpenCode itself. The docs say keys added in the terminal app with /connect are stored locally at ~/.local/share/opencode/auth.json.
October 18. Raad wrote that attackers had been trying to get into OpenCode's systems "non stop" for 48 hours.

Why people care

A provider key is a bearer credential. Whoever holds a copy can run billable requests on the owner's account until the provider revokes it. Some users have posted charges they did not make (one report of $281 on an OpenAI key and $168 on an Anthropic key). Those are users' own claims; OpenCode has not said any key was copied or used.

What the coverage is missing

1. "Distillation" is a motive, not a finding. Distillation means pulling a model's answers in bulk to train another model. Stolen keys can also just be resold or used to run up bills. Nothing disclosed so far shows which it was, and no provider has characterised it.

2. 1.4% has no denominator. Without a user count, nobody can turn the percentage into a number of people or keys.

3. Deleting a key in Console is not revoking it. According to The Hacker News, removing the key from Console does not revoke it, and a Console budget cannot cap use outside Console's own gateway. Only the provider can kill the key.

Prediction (labelled as such)

Our expectation, not a fact: more teams will treat "who holds our provider key" as a vendor-review question, the way they already do for cloud credentials. Expect gateways that hold BYOK keys to be asked for storage and rotation details.

One practical takeaway

Give every tool its own key, set a spend limit or alert at the provider, and know where to revoke. If you ever saved a key in Console, revoke it at the provider and check usage back to October 16, whether or not you got the email.

Sources

OpenCode notice on X (October 17, 2026): https://x.com/opencode/status/2111519637049319818
Dax Raad on X (Console vs OpenCode): https://x.com/thdxr/status/2111572618340188393
Dax Raad on X (October 18 update): https://x.com/thdxr/status/2111790511409258796
OpenCode docs, Providers (local key storage): https://opencode.ai/docs/providers/
The Hacker News, "OpenCode Console Breach May Have Exposed OpenAI, Anthropic, and Google API Keys" (October 19, 2026): https://thehackernews.com/2026/10/opencode-console-breach-may-have.html
Provider revoke guides: OpenAI https://help.openai.com/en/articles/8304786-keeping-your-openai-account-secure, Anthropic https://support.claude.com/en/articles/8384961-what-should-i-do-if-i-suspect-my-api-key-has-been-compromised, Google https://docs.cloud.google.com/docs/authentication/api-keys-best-practices

Written with AI assistance and checked against the sources above.

Reflection's Beam is open: 23B active, but you still have to fit 501B

Clydara — Sun, 18 Oct 2026 14:27:10 +0000

Reflection released the weights for Beam on October 16, 2026. It is the lab's first open-weight model: a sparse mixture-of-experts (MoE) model with 501B total parameters, about 23B active per token, a 1M-token context window, and an Apache 2.0 license.

Most posts stopped at the headline numbers. The part that matters if you plan to run it yourself is the gap between "23B active" and "501B on disk". Here is what was released, why people care, and what the coverage skipped.

What happened (facts)

The model. 501.3B total and 23.4B active parameters, 52 layers (3 dense + 49 MoE), 256 experts per MoE layer with 8 routed per token, gated GQA plus sliding-window attention, a 152k vocabulary, text in and text out, predominantly English. Knowledge cutoff: June 30, 2026 (model card).
The files. Instruction-tuned checkpoints in BF16, FP8 and NVFP4, plus a speculative-decoding drafter model.
The license. Apache 2.0. The model card says Reflection does not prohibit distillation, training other models on outputs, fine-tuning, quantization or merging.
Day-zero support. Transformers, vLLM, SGLang, Unsloth, Axolotl, TokenSpeed and NVIDIA Dynamo, plus hosted access through Reflection's API and partners including AWS, Google Cloud, Cloudflare, OpenRouter, Together AI and Vercel.
The harness. Reflection also open-sourced Mirror CLI, the coding-agent harness it trained Beam alongside: a Python frontend talking to a Rust agent core.

Why people care

Apache 2.0 with no field-of-use clauses is the cleanest license a frontier-sized open model can ship with. Compare that with "open-weight" licenses that add user caps or acceptable-use terms you have to read line by line. For a SaaS team, Apache 2.0 means you can fine-tune it, quantize it and serve it inside your product without a separate commercial agreement.

The other reason is cost per token. Only about 23B parameters run for each token, so once the model is loaded, generation compute is closer to a mid-size dense model than to a 500B one. Reflection also claims Beam reaches comparable quality to leading open models with about 3x fewer reasoning tokens.

What it could change (prediction, not fact)

If the token-efficiency claim holds up in independent tests, Beam becomes a realistic self-hosted backend for coding agents, where long reasoning traces are the main cost. That is a prediction. The technical report is listed as "coming", and the benchmark table on the model card is Reflection's own run (temperature 0.7, top_p 0.99).

What the coverage misses

1. "23B active" is a compute number, not a memory number. Every expert has to sit in memory, because any token can route to any of them. Rough weight-only math, our estimate rather than a published figure:

BF16 (2 bytes per parameter): about 1 TB
FP8 (1 byte): about 500 GB
NVFP4 (about 4.5 bits with scales): roughly 280 GB

That is before the KV cache, and a 1M-token context makes the KV cache the second big bill. Sliding-window attention on some layers helps, but plan for multi-GPU servers, not a single card. For most teams, a hosted endpoint is the practical way to try it first.

2. The quantized checkpoints are official. Reflection published scores for BF16, FP8 and NVFP4 side by side, and they sit within about a point of each other on most benchmarks (SWE-bench Verified: 81.6%, 80.2%, 80.7%). That is more useful than a community quant with no evals.

3. Benchmarks are self-reported for now. SWE-bench Verified 81.6%, Terminal Bench v2.1 80.1% and GPQA Diamond 90.6% are strong numbers, but they come from Reflection's own evaluation. Wait for third-party runs on your kind of task before switching anything in production.

4. The chat template is a modified Harmony format. If your serving stack hard-codes another template, tool calls are the first thing to break. Use the template shipped with the weights.

Before you self-host Beam

Try a hosted endpoint on your real prompts first.
Pick the precision you can afford in memory, then check its row in the model card's table.
Budget KV cache for the context length you actually need, not the 1M maximum.
Use the official chat template and test tool calling early.

Sources

Reflection, "Beam is now available" (October 16, 2026): https://reflection.ai/blog/beam-is-available
Model card: https://huggingface.co/reflection/Beam-1.0-501B-A23B
Hugging Face blog: https://huggingface.co/blog/reflection-beam

Perplexity open-sourced SPACE: the VM held, the network rules did not

Clydara — Sat, 17 Oct 2026 12:54:51 +0000

Perplexity open-sourced SPACE on October 15, 2026. It is the sandbox platform that has run every session of its Computer agent since July, and the code is now on GitHub under Apache 2.0.

The announcement is short. The useful part is in the security report Perplexity published a month earlier, and in the repo's install guide. Here is what happened, why people care, and what most of the coverage skipped.

What happened (facts)

What it is. SPACE stands for Sandboxed Platform for Agentic Code Execution. Each sandbox is a Firecracker microVM with its own OS. A central control plane creates, pauses, resumes and removes sandboxes.
Trust model. The sandbox is treated as untrusted. Network access and platform-held credentials are managed outside it, so an agent can call authorized services without the keys ever living in its workspace.
State. Frequent file snapshots plus checkpoints of the full running environment. It stores diffs instead of copying whole environments, which is what makes pause, resume and branching cheap.
Scale claims. Perplexity says it handles millions of sandbox creations per day, and that creation was 3 to 5 times faster than its previous provider on the same production traffic.
Interface. Written in Rust, used over HTTP and server-sent events. Lifecycle calls return an operation ID you poll.
Early adopters. Akamai has launched it on its cloud, Crusoe is adding it to Managed AI Services, and CoreWeave published setup guidance for CKS.

Why people care

Agents that run code need somewhere to run it. Until now most teams rented that from a hosted sandbox provider or glued together containers. A production sandbox with recovery and egress control built in, under a permissive license, is a real option to self-host.

What the coverage skipped

1. The VM was not the weak point. The network was. In "Escaping SPACE: Part I", nine models got root inside a guest VM. Across 108 escape runs, none reached the host. But with partial network access (package mirrors allowed), four models got past the egress policy in 11 of 54 runs. Two tricks: forging a DNS reply so an allowed hostname mapped to a blocked IP, and using a shared CDN IP to reach a different service behind it. Perplexity fixed both (source-address validation, plus TLS termination that checks SNI and Host against the allowlist), and neither worked in the retest.

2. It is not just Perplexity's problem. The same report tested ten other sandbox platforms. Eight had at least one network-policy bypass. Vendors responded with fixes, documentation changes, or both.

3. You need real hardware access to run it. The install guide asks for a Linux x86_64 host with /dev/kvm, /dev/net/tun, loop devices, btrfs and Docker with privileged containers. It does not run directly on macOS, and a cloud VM must support nested virtualization.

4. The E2B compatibility wrapper is partial. There is an E2B-compatible API, but create options like mcp, volumeMounts and iam are listed as unsupported, and unsupported endpoints return 501. Fields marked "incubating" sit outside the supported contract.

What it could change (prediction, not fact)

Our read: the biggest effect is on how people judge sandboxes, not on who hosts them. "Is it a microVM?" stops being enough. The question becomes "what does your egress gateway trust, and has anyone attacked it with an agent?" Expect more vendors to publish agent red-team results, because Perplexity just set that bar.

A practical check for your own setup

If your agents run with a domain allowlist, test this today:

# from inside the sandbox: allowed host as SNI, different Host header
curl -sv https://pypi.org/ -H "Host: some-other-tenant.example" -o /dev/null

If the gateway only checks the destination IP, a request like this can reach a tenant you never allowed. Pass/fail tells you whether you need TLS-aware egress rules.

Sources

Perplexity, Open-sourcing SPACE (Oct 15, 2026): https://www.perplexity.ai/hub/blog/open-sourcing-space
Repository: https://github.com/perplexityai/SPACE
Escaping SPACE: Part I (Sep 23, 2026): https://www.perplexity.ai/hub/blog/escaping-space-part-i
Install guide: https://github.com/perplexityai/SPACE/blob/main/docs/installation.md

Which boundary does your agent setup trust more today: the VM or the network rules?

This post was drafted with AI assistance and edited and fact-checked against the sources above by the Clydara team.

Muse Spark Open: what Meta's "open-weight" license actually lets you do

Clydara — Fri, 16 Oct 2026 13:16:09 +0000

On October 15, 2026, Meta released the weights of Muse Spark Open, a natively multimodal mixture-of-experts model with 816B total parameters (42B active per token) and a 1M-token context window, built for coding and agentic work. Meta calls it "the most capable US open-weight model to date". That line is Meta's own claim, based on Meta's own benchmark table.

What happened

Weights are on Hugging Face (BF16 and NVFP4 checkpoints), plus Amazon SageMaker AI, Google Cloud Model Garden and Microsoft Foundry Models.
Hosted APIs launched the same day at Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter and Together AI.
It runs on SGLang, vLLM, TensorRT-LLM, Transformers, MLX, llama.cpp and Unsloth. Meta shows it running on two Apple M5 Ultra Mac Studios with 512 GB each.
Architecture (Hugging Face model card): 256 experts per MoE layer, 8 routed per token; text, image, audio and video in, text out.

Why people care

Chinese labs (Qwen, Kimi, GLM) have led open weights for most of 2026. This is a US lab answering with a large, agent-focused model that you can actually download and self-host.

What the coverage skips

1. Active vs total parameters. 42B active sets the compute per token. All 816B weights still have to sit in memory. The model card asks for roughly 700 GB of VRAM for NVFP4 and about 2 TB for BF16. Cheap per token is not cheap to host.

2. The license is not OSI open source. The Muse Model License opens like MIT ("free of charge... without restriction"), then adds conditions:

Section 2: any product that uses the model or a "Derivative" must prominently display "Built with Muse Spark Open" (UI, docs, website or settings).
"Derivatives" includes any model "trained, modified (including fine-tuned), distilled, or otherwise improved using the Software or any outputs or results thereof". A small model you fine-tune on Muse outputs counts.
Section 3: if you sell model access via an API ("Model as a Service") and your group's gross revenue passes $20 million in any 12 months, you must sign a separate agreement with Meta first. Internal use, research, and powering features of your own product are exempt.
The attached Usage Policy rules out, among other things, operating critical infrastructure, transportation technologies or heavy machinery, and says the model is not intended for anyone under 18.

3. The benchmarks are self-reported. Meta says a fuller evaluation report is coming. Independent indexes so far place it behind the strongest Chinese open models on general intelligence scores.

Facts vs prediction

Everything above comes from Meta's announcement, the Hugging Face model card and the license text. My read, a prediction rather than a fact: most teams will use it through hosted APIs, not local hardware, and the derivative clause will matter more than the $20M clause for small teams running distillation pipelines.

Practical takeaway

Read LICENSE.md before you build anything on it, especially if you plan to distill or fine-tune on its outputs.
Add the "Built with Muse Spark Open" line wherever you ship it.
Run 20 to 50 of your own real tasks through a hosted endpoint before trusting any leaderboard.

Sources:

Meta AI Research, Introducing Muse Spark Open (Oct 15, 2026): https://research.meta.ai/blog/muse-spark-open
Muse Model License: https://huggingface.co/meta-models/Muse-Spark-Open-816B-A42B/blob/main/LICENSE.md
Hugging Face launch post: https://huggingface.co/blog/meta-muse-spark-open

This post was written with AI assistance and edited for accuracy.

NVIDIA Open-Sourced Run:ai. Here Is What Actually Changed for Kubernetes GPU Teams

Clydara — Thu, 15 Oct 2026 14:08:56 +0000

On October 13, 2026, NVIDIA released the full Run:ai GPU orchestration platform as open source, inside its new DSX AI Factory GitHub organization. Most coverage stopped at "NVIDIA open-sources Run:ai." The details matter more than the headline, so here is what shipped, why platform teams care, and what the announcement leaves out.

What happened

NVIDIA published the complete Run:ai platform code plus four components you can adopt on their own:

KAI Scheduler: the Kubernetes-native scheduler behind Run:ai. Gang scheduling, fair-share and quotas, topology-aware bin-packing, GPU sharing (MIG, MPS, time slicing, HAMi) and Dynamic Resource Allocation support. Apache 2.0 and a CNCF Sandbox project.
GPU Fractioning Operator: wires CUDA-native GPU fractions into Kubernetes, with a per-pod metrics exporter. It is scheduler-agnostic.
KAI Resource Management: projects, departments, hierarchical quotas and node pools.
Workload Map: a Go library that describes PyTorchJob, RayCluster, JobSet, KServe and custom CRDs once, so tools can schedule and observe them without hardcoding each type.

A Helm-installable "Community Product" build is also on NVIDIA NGC. Eight partners, including Crusoe, Mirantis, Nebius, Rafay, Spectro Cloud and vCluster, announced integrations the same day.

Why people care

GPU time is the most expensive line on most AI infrastructure bills, and plain Kubernetes was not designed to share GPUs fairly between teams. Until now, the org layer (who gets what share of the cluster) and fractional GPUs were the paid parts of Run:ai. Both are now code anyone can read, fork and run.

What could change

Smaller AI clouds and internal platform teams get a production-tested quota and fair-share layer without a commercial contract. NVIDIA's own example: guarantee 50% of a cluster to research without letting any other team grab the rest.
Fractional GPUs for notebooks and small models become easier to justify, because sharing no longer depends on a proprietary driver hook.
Tooling vendors may converge on Workload Map instead of writing a private integration per CRD. That one is a prediction, not a fact: watch its ADOPTERS file.

What most coverage misses

The fractioning code was retired, not opened. NVIDIA says its proprietary fractional-GPU implementation has been retired in favour of native fractions in CUDA 13.4. The new operator is the Kubernetes glue for that driver feature, so check your CUDA and driver versions before planning around it.
Free does not mean supported. The NGC Community build needs no Run:ai subscription, but NVIDIA states that enterprise support is not included, and downloading it means accepting NVIDIA's software license terms on top of the open source licenses.
KAI Scheduler was already open. It went Apache 2.0 earlier; the genuinely new code is the platform layer, resource management, Workload Map and the operator.
You do not need the whole stack. NVIDIA says KAI Scheduler can run in an existing cluster alongside your current software, and Workload Map works offline on unstructured objects.

Facts vs predictions

Facts: the repositories, the four components, the CUDA 13.4 change, the NGC support terms and the partner list are all in NVIDIA's technical blog. Predictions: wider adoption by smaller clouds and convergence on Workload Map. Nobody has public adoption numbers yet.

Where to start

If you run shared GPU nodes today, start with KAI Scheduler alone in a staging cluster, then try the fractioning operator on notebook workloads once your nodes are on a CUDA 13.4 capable driver.

Sources: NVIDIA Technical Blog, Oct 13, 2026 · dsx-ai-factory/run-ai on GitHub

Which part would you actually adopt first: the scheduler, the quotas or the GPU fractions?

This post was drafted with AI assistance and reviewed and edited by the Clydara team.

The iPhone Duo Web Checklist: 9 Things to Verify Before October 23

Clydara — Tue, 13 Oct 2026 13:18:49 +0000

In September, a post titled "Dear God websites look horrible on iPhone Duo" climbed to the top of r/webdev. Two screenshots and one complaint: with the phone closed, sites were using about 70% of the screen. It passed 3,000 upvotes. Much of the thread was aimed at Safari for keeping its controls on screen on the smaller, closed display. Fair. But plenty of the ugliness in those screenshots was ours: layouts built for three fixed widths.

Pre-orders open October 16. The phone goes on sale October 23. Below is the checklist we'd work through before then. Nothing here assumes you own the device, because almost nobody does yet.

First, the numbers (and why you shouldn't trust them)

Apple publishes physical pixels only. The inner display is 1878 x 2670 and the outer one is 1398 x 2034. Divide by the usual iPhone pixel ratio of 3 and you get the commonly quoted estimates:

State	Screen in CSS px (estimated)
Closed, outer display	about 466 x 678
Open, held like a book	about 890 x 626
Open, rotated	about 626 x 890

The open device is wider than it is tall (164.6 mm by 117.8 mm), which is why most write-ups quote 890 as the unfolded width. So the jump people talk about, 466 to 890 in one motion with no reload, is real in the common case.

Now the catch. Safari on the Duo keeps a strip of controls down the right edge. One design studio, working in Apple's iOS 27.1 simulator, measured the outer screen's web view at 466 points but the layout viewport at 382. That means innerWidth may be smaller than every number in the table.

Treat the table as a test plan. Never treat it as a breakpoint list.

1. Find out where your breakpoints actually land

Default framework breakpoints were not designed with this phone in mind. At 890px, Tailwind and Bootstrap both serve their md (768px) tier, which most teams treat as "tablet portrait". At 626px, Tailwind's first step (sm, 640px) doesn't fire at all, so a 7.6-inch screen gets the exact CSS of a 6.3-inch iPhone.

Paste this into DevTools on your production site to see what you're really shipping:

// Lists every width breakpoint in same-origin stylesheets.
const widths = new Set();
let skipped = 0;

const walk = (rules) => {
  for (const rule of rules) {
    if (rule instanceof CSSMediaRule && /width/.test(rule.conditionText)) {
      for (const [, n, unit] of rule.conditionText.matchAll(/(\d+(?:\.\d+)?)(px|em|rem)/g)) {
        widths.add(unit === 'px' ? Number(n) : Number(n) * 16);
      }
    }
    if (rule.cssRules) walk(rule.cssRules);
  }
};

for (const sheet of document.styleSheets) {
  try { walk(sheet.cssRules); } catch { skipped++; }
}

console.log([...widths].sort((a, b) => a - b), `${skipped} cross-origin sheets skipped`);

If skipped is above zero, the list is incomplete. Check where 382, 466, 626 and 890 fall. If two of them hit the same tier and the layout looks wrong at one of them, you've found your first bug.

Don't fix it with @media (width: 890px). The next foldable will ship different numbers. Move the boundary to wherever your content starts to look cramped or stretched.

2. Let components respond to their container

Page breakpoints answer "how wide is the window?" Most layout bugs on the Duo are really "how wide is this card?" Container queries answer that directly, and they keep working in Split View, where your page might be half the inner screen.

.card-list {
  container: cards / inline-size;
}

.card {
  display: grid;
  gap: 1rem;
}

@container cards (width >= 34rem) {
  .card {
    grid-template-columns: 12rem 1fr;
    align-items: start;
  }
}

The card now goes side by side when its column has room, whether that's on an unfolded Duo, a laptop or a narrow sidebar. Forms, pricing tables and product grids benefit the most.

3. Stop sizing heroes with `100vh`

vh maps to the large viewport, the size with browser UI retracted. On a 678px-tall outer screen, a 100vh hero with a headline, a subhead and a button can push the button below the fold.

.hero {
  min-height: 100vh;   /* fallback for old browsers */
  min-height: 100svh;  /* small viewport: never taller than what's visible */
}

.app-shell {
  height: 100dvh;      /* dynamic: follows toolbars as they move */
}

Our rule: svh for marketing heroes, dvh for full-screen app shells, vh almost nowhere. One caveat worth checking yourself: the same studio reported 100vh resolving to 598 on a 678px outer screen in the simulator, and said no CSS unit matched the visible height under Safari's floating toolbar. Open your hero in the simulator and look before you trust any unit.

4. A wide screen is not a mouse

At 890px, plenty of sites switch to the desktop nav. That nav usually opens on :hover. On a touch screen, hover is emulated with an awkward tap, so the mega menu either flickers or never opens.

Gate hover behaviour on the input type instead:

.nav-item > .submenu { display: none; }

/* Works everywhere: keyboard focus and an explicit toggle */
.nav-item:focus-within > .submenu,
.nav-item[data-open] > .submenu { display: block; }

/* Only real hover devices get hover menus */
@media (hover: hover) and (pointer: fine) {
  .nav-item:hover > .submenu { display: block; }
}

/* Bigger hit areas for fingers */
@media (pointer: coarse) {
  .nav-item > a,
  .nav-item > button { min-block-size: 2.75rem; }
}

hover and pointer describe the primary input. If you need "does any input hover?", use any-hover and any-pointer. Apple says Apple Pencil support for the Duo arrives later this year, which is one more reason not to bake "this phone never hovers" into your JavaScript.

5. Make your JavaScript resize-safe

CSS reflows on its own. JavaScript that measured once at load does not. Look for these in your codebase: const isMobile = window.innerWidth < 768, chart libraries initialised with a fixed width, carousels that calculate slide counts on mount.

Use a media query listener for layout modes and ResizeObserver for element sizes:

const wide = window.matchMedia('(width >= 48rem)');

function setLayout(isWide) {
  document.documentElement.dataset.layout = isWide ? 'wide' : 'narrow';
}

setLayout(wide.matches);
wide.addEventListener('change', (e) => setLayout(e.matches));

const chartBox = document.querySelector('.chart-wrap');
const ro = new ResizeObserver(([entry]) => {
  chart.resize(Math.round(entry.contentRect.width));
});
ro.observe(chartBox);

Both are Baseline widely available. The harder bug is state. If your framework unmounts the mobile nav and mounts a desktop one at a breakpoint, the user unfolds the phone and loses whatever they typed, the open accordion and sometimes their scroll position. Prefer one component that restyles over two components that swap.

6. Delete user-agent layout branching

The Duo identifies as an iPhone. Code like this serves your phone layout to a screen with room for a sidebar:

// Wrong on the largest iPhone Apple has made
const isMobile = /iPhone/.test(navigator.userAgent);

Search your repo, your tag manager and your server templates for this pattern. Replace it with media queries, container queries, or matchMedia checks that listen for changes.

7. Split your safe-area padding

If you draw edge to edge, safe-area values only apply with viewport-fit=cover in the viewport meta. On the Duo, the left and right insets are reported to differ, so the old shorthand that copies one value to both sides is a quiet bug:

/* Before */
.toolbar { padding-inline: env(safe-area-inset-left); }

/* After */
.toolbar {
  padding-left: max(1rem, env(safe-area-inset-left));
  padding-right: max(1rem, env(safe-area-inset-right));
}

Reports conflict on whether Safari's right-hand control strip shows up in these insets at all, so verify with your own eyes in the simulator. And keep your primary call to action out of the dead centre of wide layouts. That's where the fold runs, and right now CSS can't tell you exactly where it is.

8. Don't wait for fold detection

The web has APIs for this: Viewport Segments (horizontal-viewport-segments, visualViewport.segments) and Device Posture. Chrome supports them on Android foldables. WebKit's standards-positions issue for Viewport Segments, filed in March 2024, is still open with no stated position. A commenter on that issue noted in September that the feature appears behind a flag in the iOS 27.1 simulator. Behind a flag means your visitors won't have it.

Write the single-viewport layout first and treat segments as an extra:

const segments = window.visualViewport?.segments;

if (segments && segments.length > 1) {
  document.documentElement.dataset.fold = 'split';
} else {
  delete document.documentElement.dataset.fold;
}

9. Test the unfold itself

A static screenshot at 890px tells you very little. The bugs happen during the transition. Here's the loop we'd run:

In Chrome or Safari responsive mode, set 466 x 678. Open the menu, type into a form, scroll halfway down a long page.
Without reloading, switch to 890 x 626. Then 626 x 890. Then back to 466.
Check what survived: scroll position, form input, open menus, playing video, sticky headers.

Add a dev-only logger so you can see what fired and when:

new ResizeObserver(() => {
  console.log('viewport', innerWidth, 'x', innerHeight);
}).observe(document.documentElement);

On a Mac, you can go further. Per one studio's walkthrough, the Duo only appears in the iOS 27.1 simulator, and Xcode 27 moves simulators into an app called Device Hub:

xcrun simctl create "iPhone Duo" com.apple.CoreSimulator.SimDeviceType.iPhone-Duo com.apple.CoreSimulator.SimRuntime.iOS-27-1
xcrun simctl boot "iPhone Duo"
xcrun simctl openurl booted http://localhost:5173

Safari's Develop menu on the Mac then attaches Web Inspector to the simulator page. Also drag the Split View divider through its full range, since that resizes your page to widths no device table lists.

The short version for site owners

If you don't write code, ask whoever maintains your site two questions this week. What does our site look like at 466 and 890 pixels wide? And what happens to a half-filled enquiry form when the phone opens? Layout bugs like these rarely throw errors. They just lose leads quietly, which is the same pattern behind most of the reasons startup websites fail to generate leads that we've written about before.

Which of these bit you first? We're especially curious whether anyone has a clean answer for Safari's side strip yet.

Sources

Apple Newsroom, iPhone Duo announcement (dates, displays, Split View, Apple Pencil): https://www.apple.com/in/newsroom/2026/09/apple-unveils-iphone-duo
Apple, iPhone Duo tech specs (pixel dimensions, physical size): https://www.apple.com/iphone-duo/specs/
screensize.io, iPhone Duo viewport estimates: https://www.screensize.io/blog/iphone-duo.html
MDN on viewport units, container queries, hover, pointer, ResizeObserver: https://developer.mozilla.org/
WebKit standards position on Viewport Segments: https://github.com/WebKit/standards-positions/issues/327

Written by the team at Clydara, a web and software studio in Lahore that builds and fixes sites like these for clients. We used AI tools to help with research and drafting, and checked every claim against the sources above.

DEV Community: Clydara

PHP's two critical RCE fixes: the bug wasn't new, the decision was stuck

What happened (facts)

Why people care

What the coverage is missing

Prediction, labeled

What to do today

Sources

GitHub's new npm package firewall only protects what you route through it

What was announced

Why people care

What it could change

What the coverage is missing

Practical takeaway

The OVHcloud CLI release swap: why the checksum file didn't help

What happened (facts)

Who was exposed

What the coverage mostly skips

What is not known yet

What to do

Sources

OpenCode's Console breach: when a middleman holds your API keys

What happened (facts)

Why people care

What the coverage is missing

Prediction (labelled as such)

One practical takeaway

Sources

Reflection's Beam is open: 23B active, but you still have to fit 501B

What happened (facts)

Why people care

What it could change (prediction, not fact)

What the coverage misses

Before you self-host Beam

Sources

Perplexity open-sourced SPACE: the VM held, the network rules did not

What happened (facts)

Why people care

What the coverage skipped

What it could change (prediction, not fact)

A practical check for your own setup

Sources

Muse Spark Open: what Meta's "open-weight" license actually lets you do

What happened

Why people care

What the coverage skips

Facts vs prediction

Practical takeaway

NVIDIA Open-Sourced Run:ai. Here Is What Actually Changed for Kubernetes GPU Teams

What happened

Why people care

What could change

What most coverage misses

Facts vs predictions

Where to start

The iPhone Duo Web Checklist: 9 Things to Verify Before October 23

First, the numbers (and why you shouldn't trust them)

1. Find out where your breakpoints actually land

2. Let components respond to their container

3. Stop sizing heroes with 100vh

4. A wide screen is not a mouse

5. Make your JavaScript resize-safe

6. Delete user-agent layout branching

7. Split your safe-area padding

8. Don't wait for fold detection

9. Test the unfold itself

The short version for site owners

Sources

3. Stop sizing heroes with `100vh`