How Newly is responding to recent security vulnerabilities

How Newly is responding to recent security vulnerabilities

Certificate trust changes, dependency updates, and the layers protecting Newly’s development environments.

Timothy Lindblom

Founder, Newly

Recent security disclosures have affected software used across the internet, from certificate authorities and application runtimes to AI libraries and the Linux kernel. For anyone building software, these issues raise a practical question: what is being handled by your platform, and what still needs your attention?

At Newly, we’ve removed the affected certificate authority from our trust configuration and updated LiteLLM. We also use a web application firewall and run development workloads in microVMs through third-party infrastructure providers.

Here’s what those measures address, and where their protection has limits.

  1. Removing the affected certificate authority

    The eMudhra incident involved weak private keys for eight intermediate certificate authorities. Those keys could be recovered and used to forge certificates, allowing an attacker who could intercept a connection to impersonate a legitimate service to clients that still trusted the affected authorities.

    Researcher Wayne reported the issue to browser vendors on October 17. The public incident report includes his account and proof attachments. You can read eMudhra’s incident statement and independent coverage from BleepingComputer and Ars Technica.

    We’ve removed the relevant CA from Newly’s trust configuration. Removing that trust prevents affected certificate chains from being accepted through the updated configuration.

  2. Filtering malicious web traffic

    Newly uses a web application firewall, or WAF, to help filter malicious incoming requests before they reach protected services.

    This provides an additional layer of protection against attacks delivered through web traffic. A firewall does not replace patched runtimes and dependencies, and it does not cover every way vulnerable software can be reached. Applications also process responses from external services and execute installed packages.

  3. Updating LiteLLM

    We’ve updated LiteLLM in Newly’s infrastructure in response to the recent security disclosures. Dependencies used by the platform and dependencies installed in individual customer projects are separate: updating Newly’s copy does not automatically update a copy included in your own application.

    If your project uses LiteLLM directly, review its installed version against the project’s security guidance and update it where necessary.

  4. Isolating workloads with microVMs

    Newly runs development workloads in microVMs supplied by third-party infrastructure providers. MicroVMs give workloads a virtual machine boundary, with a separate guest kernel rather than the shared host kernel used by conventional containers. That boundary helps contain the effects of a compromised workload and reduces opportunities for it to affect neighboring environments.

    Isolation is one layer of protection. Software inside a microVM still needs security updates, and host infrastructure still requires security maintenance from our providers.

What this means for your projects

The platform measures described above are handled by Newly. For dependencies and runtimes included in your own application, review applicable security advisories, apply updates, and rebuild or redeploy so the fixes reach the running application.

Our approach combines dependency updates, certificate trust changes, traffic filtering, and workload isolation. Each addresses a different part of the risk, and each matters when new vulnerabilities emerge.

We’re also adding penetration testing to Newly through red.run.cloud, to help you find security weaknesses in your applications.