|
By Ben Bader
This post is an unfortunate affirmation of our prior research into abandoned open-source packages, where we found that 11% of the most-downloaded packages have been abandoned and not actively maintained, becoming invisible vulnerabilities to your scanner. Today we share a zip-slip vulnerability we found in extract-zip (CVE-2026-19693), an npm package with over 20 million weekly downloads.
|
By Lev Pachmanov
How to evaluate your options, price the status quo, and make a decision your executive team will actually approve. A note on the numbers. The salaries, headcounts, and costs in this guide are illustrative. They're drawn to be realistic so the math works the way it does in a real budget meeting - but they're examples, not benchmarks. Replace them with your own.
|
By Ben Bader
We discovered this new vulnerability as part of our abandoned-packages research. Despite what seems like a 2-year hiatus, fflate is one of the few popular npm packages that released a fix for the vulnerabilities we found merely using Sonnet-4.6, giving its 50M+ users a chance to upgrade to a safe version.
|
By Ben Bader
In a previous post we looked at the skills CLI by vercel-labs/skills and ways for a malicious skill to overwrite an existing trusted skill by using homoglyph names or abusing weird CLI behaviors. This post will delve into an OSC-8 escape injection we found in the skills add command, which lets a skill author write arbitrary text to the console and clickable links as if it's part of the CLI's output.
|
By Ben Bader
brace-expansion is a very popular npm package with over 38 billion all-time downloads (yeah, over 38,000,000,000) and used by tooling almost every JavaScript project relies on - eslint, glob, and npm itself. Despite being in the public eye for a while, we found a new Denial-of-Service vulnerability that could affect millions. This post walks through what the package does, existing issues that were fixed, and the new one we found - CVE-2026-13149.
|
By Ben Bader
Agent skills are the newest piece of plumbing quietly making its way onto developer machines. They're easy to install, they get to call into the user's tools on the agent's behalf, and once they're in place they tend to stay in place. While auditing the popular installer vercel-labs/skills, we saw several ways a bad actor can make the tool install something other than what the user thought they were installing.
|
By Amit Agam
Most internal AI initiatives fail the same way: someone builds a thing, sends a Slack announcement, runs a lunch-and-learn, and three months later the thing has two active users. The failure mode isn't the AI. It's the ask. Every new surface is a decision engineers have to make: remember to open it, remember to use it, remember to trust it. Seal's approach for our own R&D team was to eliminate the ask entirely. The AI goes where our engineers already are, at the moment they need it.
|
By Alon Navon
In the fast-moving world of software supply chains, the discovery of a malicious version of a popular library often triggers a state of emergency. Traditional security tools take a reactive approach: they scan, they find a match, and they fail the build. But what happens if the malicious version was merged before it was flagged? What if it’s already running in your production containers? Or what if it’s being pulled dynamically across hundreds of different pipelines?
|
By Lev Pachmanov
Building a supply chain security company comes with an uncomfortable truth: our remediated packages run inside our customers' production environments. A compromise on our end is a compromise on theirs. We take that responsibility seriously. I want to pull back the curtain on how we actually secure our own supply chain - from the code we write, to the artifacts we deliver, to the infrastructure that holds it all together.
|
By Alon Navon
A definitive guide to how automated and human-reviewed patch-in-place remediation solves both direct and transitive open source vulnerabilities - without forcing risky upgrades. Learn why traditional tools miss transitive risk, and how to evaluate modern platforms based on SLA, provenance, and CI/CD fit.
|
By Seal Security
In this white paper we conducted extensive research on how organizations manage their open source vulnerabilities. This white paper explores the challenges and limitations they encounter, as well as the available solutions.
- August 2026 (15)
- July 2026 (4)
- June 2026 (2)
- May 2026 (1)
- April 2026 (3)
- March 2026 (1)
- January 2026 (2)
- December 2025 (6)
- November 2025 (5)
- April 2025 (1)
- March 2025 (3)
- February 2025 (2)
- January 2025 (1)
- December 2024 (3)
- August 2024 (1)
- June 2024 (1)
- May 2024 (1)
- February 2024 (1)
- January 2024 (1)
- December 2023 (1)
- August 2023 (1)
Seal Security provides standalone security patches that are fully compatible with existing versions of open source packages, ensuring seamless and predictable fixes for vulnerabilities in both application code and Linux operating systems.
Eliminate all your open source risks with one unified solution:
- Secure open source vulnerabilities without impacting your development: Strengthen your supply chain with patches for both direct and transitive dependencies.
- Secure containers and base images: Secure your existing images without upgrading—even if you're running older distributions.
- Secure end-of-life code: Receive security patches post-EOL for platforms like CentOS and RHEL 6, and continue to meet compliance standards.
- Secure legacy and hard-to-manage code: Streamline the process of fixing security issues in old or legacy code. Address vulnerabilities in difficult-to-patch applications—even those outside your control.
- Uphold compliance and meet customer SLAs: Maintain vulnerability-free images to ensure you meet your customers' SLA requirements and successfully pass any security audit, including FedRAMP, PCI DSS 4.0, and NYDFS 500.
We fix all open source vulnerabilities so you don’t have to.