devopsy.kinsta.cloud

Tag: artifact repositories

More JFrog Artifactory Bugs Are Under Attack, and All Three Have Patches

Artifact repositories sit in an odd blind spot for many security teams. They don’t face the internet as a web app does, and they don’t hold customer data as a database does. But they hold something arguably more valuable: the binaries, containers, and packages that every build pipeline pulls from before code ships. Compromise the repository, and you’re not attacking one application. You’re attacking everything downstream.

That’s the backdrop for a new report from Wiz detailing active exploitation of three JFrog Artifactory vulnerabilities, all of which already have patches available. The gap between “patched” and “actually applied” is where this story lives.

The most serious of the three, CVE-2026-82329, is an authentication-bypass bug that lets an unauthenticated attacker with network access reach the repository and walk straight into administrative privileges. JFrog shipped a fix on August 28. Wiz says multiple threat actors are exploiting it independently, which usually signals that proof-of-concept details spread fast once a critical bug like this gets attention.

The other two are being chained together. CVE-2026-42018 is an improper-authentication flaw that returns internal anonymous-user tokens to callers even when anonymous access is disabled, giving an attacker a foothold to authenticate as if they belonged there. JFrog patched it on August 12. CVE-2026-42016 is a privilege-escalation bug rooted in improper token-scope validation, letting a low-privileged, already-authenticated user climb to permissions they were never granted. That one was patched earlier still, on July 27. Wiz’s researchers describe attackers combining the two to go from a low-privilege foothold to full administrative control of the Artifactory instance.

Once inside, the attackers aren’t just poking around. Wiz found custom Rust-based backdoors installed for persistence, Groovy plugins used to execute arbitrary code on the server, and web shells left behind for remote access. That’s a full toolkit built specifically for what an Artifactory server is: a place where malicious code, planted deep in a build pipeline, can quietly ride into every downstream product that pulls a package from it.

What makes this a story about patch management as much as it’s a story about vulnerabilities is how long these bugs have stayed exploitable after fixes shipped. Wiz’s telemetry shows CVE-2026-42016 still present in 59% of scanned instances six weeks after the patch went out. CVE-2026-42018 was still unpatched in 62% of instances a full month later. Even the critical bypass, CVE-2026-82329, was still exploitable in 49% of instances two weeks after JFrog fixed it. As Wiz put it in its research, “patching velocity has been slow.”

Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group, sees these numbers as a mismatch in how teams decide what to patch first. “Patch urgency still prioritizes internet exposures versus downstream dependence, which is why a repository manager can sit unpatched for weeks while a public web app gets fixed in hours or days,” he said. “Compromising a repository is a software supply chain security event. Every build that pulls from it inherits the result.” His prescription is direct: “Build infrastructure deserves the same patch clock as anything customer-facing. Security teams should be asking today who holds administrative tokens on their repository and what those tokens can reach.”

None of this is unique to JFrog. Artifact repositories, package registries and build servers have become a recurring target precisely because they sit upstream of so much else, and because they don’t always get the same patching discipline as customer-facing systems. A vulnerability in a repository manager doesn’t generate the same urgency as one in a public web app, even though the potential blast radius- poisoned builds moving downstream to every team and product that depends on them- can be larger.

It also helps explain why attackers keep chaining lower-severity bugs together instead of waiting for the next critical one. A privilege-escalation flaw and an authentication weakness, each modest on its own, add up to full administrative control once combined. That’s a pattern worth watching beyond this one product: two “high” severity CVEs sitting unpatched next to each other can quietly become as dangerous as a single “critical” one, and vulnerability scoring rarely accounts for that kind of combination.

For teams running Artifactory, the fix itself isn’t complicated: three CVEs, three patches, all available for weeks. The harder part is organizational. Build infrastructure tends to be treated as internal plumbing, patched on whatever cadence feels convenient rather than the cadence the threat actually requires. That habit is exactly what these exploitation numbers measure, and it predates this specific set of bugs and will outlast them too.

The practical takeaway is to treat repository managers, CI/CD servers, and anything else your build pipeline depends on as first-class attack surface, not background infrastructure. That means patching them on the same urgent timeline as anything internet-facing, auditing who holds administrative tokens, and watching for exactly the kind of persistence mechanisms Wiz found here: unexpected plugins, unfamiliar service accounts, or processes that don’t belong in a repository server’s normal operation. The vulnerabilities get fixed. Whether they get exploited in your environment depends on how fast that fix reaches production.

September 14, 2026
From Automated Cloud Deployment to Progressive Delivery

Your team is on its agile journey and you can more or less track a deployment from a story, through git commits, to an automated builder, to an artifact repository, into a container and then onto the cloud. Or, in fact, any other of the many valid variants that lead you to believe your deployments are largely automated. What you can point to is a business request comes in and the result is a service or a new app. Your purview seems to stop before your users can even respond though. Is that good enough?

Let’s go back to the early idea of a release. It was a collection of all the features and fixes the loudest stakeholders had persuaded the product owner to put at the top of the story list. A date was promised, but QA was late, and the persistent stakeholders squeezed a little more juice out of a story. Then it was stuffed into a ball and delivered to your servers overnight, lest anyone notice. The next day, the developers had to deal with the fallout as the support queues grew with confused users.

While developers were getting the hang of the agile notion of automated deployment, the release lifecycle did pretty much end with a deployment going live. This gave certainty that what had been built and placed in the artifact repository was the same thing the testers had seen in the staging environment. And it also had the changes Jira said it had.

This type of release was very much like a birthday present. Your uncle talked to your dad briefly, without your knowledge, and agreed you really would benefit from a new pair of socks. Then these were delivered on the day with the receipt in the bag, just in case you needed to take them back.

The first evolution came with the concept that a release wasn’t exactly synonymous with a deployment. Finally, the end-user’s perspective nudged its way into corporate release strategy–updates could be deployed without necessarily impinging directly on every user. What if there were two identical release environments with clever network switching, meaning only one was truly live? This type of flip-flop arrangement (sometimes referred to as blue/green deployment) allowed changes to be tested internally in a realistic environment before going live.

It was the advertising industry that prompted the idea of A/B testing. Instead of guessing one variation of a campaign might be superior to another, the surprisingly scientific method of using a controlled sample and a variation was used on audiences to see which they preferred. In the digital age, it is possible to deploy two variations of the same release to different server sets. This might mean each user session could be using either release. It would then be necessary to associate the resulting click-throughs, or whatever success measurement is chosen, to the specific release flavor. The worth of this kind of experimentation was only as good as the question you asked, but it was at least observing real user interaction.

Moving on, DevOps environments began to use more feature flags or toggles. These were code paths that could deliver feature changes in live servers, controlled through configuration changes. This reduced the need to re-deploy to make certain changes. Release minded teams were coalescing around configuration, as opposed to just code. Whereas code once compiled and built was locked away in unreadable artifact files–a larger stakeholder community could administer configuration files, usually encoded in English. This helped to keep the feature changes closer to the stakeholders and less likely to slip back into silos.

As a more defined understanding of delivery arrived, so did the understanding of the user community. It used to be the case that a user was a one-line entry in a database. Even firms whose business is not mining their user’s data understand there are different sets of users for products and services.

Traditionally, there has always been internal users or beta testers–those within the firm whose job is to check the bits they understand, or are responsible for, are working as expected. Then outside the firewall, there are the tech savvy community who actively want the latest updates. These guys report bugs and often compare your product with the competition, perhaps using both. This audience will not lose their marbles if you deliver a bug to them. More to the point, they will notice rapidly–perhaps telling everyone on social media–about your failings.

The disengaged users who may only have the free version or tier of your product come next. These people are more likely to work on impressions and are best not disappointed. They are also unlikely to be keen on updates. Finally, the large core of solid users who pay their way, just want things to work and need to understand a path to continuity will already appreciate the software and will understand the roadmap by osmosis. These will probably include your biggest users, too. Of course, if you have no way of distinguishing your users all the above is moot.

With services sitting on a public cloud and CDN like edge services such as CloudFront, the ability to release by territory is much more straightforward. This is also increasingly necessary for legal reasons–EU regulations, for example. This allows for tactical releases to communities in different time zones and sizes. The practice of deploying changed services to a small group for risk mitigation, or “canarying,” is another method that takes advantage of smart routing. This requires the ability to quickly observe and rollback releases though.

Today, most software has some degree of dark launch that restricts the visibility of a release to the appropriate community, until all is well. In this sense, a progressive delivery (defined as “continuous delivery with fine-grained control over the blast radius” by James Governor) can be seen as the virus-like spreading of your software or services from your development teams’ laptops to the last user.

Observing service use is simply part of the core concern of virtually every company in the tech space. From this perspective, progressive delivery changes the way to see your development team as mere builders to user fulfillment specialists, which of course, they always were.

The future will undoubtedly involve increasingly customer-driven releases, which goes hand in hand with the increasing use of data science to study user communities and their exhaust. The important take away is to make sure your team is reaching further to the right-hand side of the product journey, and keep the user’s reaction to what you make as a larger part of your sensory input. Think more about constant small changes and less about ceremonial releases.

— David Eastman

October 10, 2019
Anaxi Delivers Project Management App for DevOps

Anaxi, a provider of project management software designed specifically for DevOps teams, has made its web application generally available. The web application complements an existing iPhone application, while an Android version of the company’s project management application is still under development.

Company CEO says Marc Verstaen said that as DevOps has evolved around multiple repositories, IT organizations are finding it challenging to keep track of code from projects they are using within what applications. Anaxi is designed to not only make it simpler to navigate repositories, but also apply analytics to track individual developer productivity and team performance. Project managers now can, for example, analyze efforts in terms of code added and removed, refactoring and code churn on a weekly basis.

Armed with that intelligence, IT operations teams will be better able to prioritize development plans based on the dependencies that exist between the various components that make up an application, said Verstaen. The number of those dependencies is only expected to increase as organizations increasingly shift away from building monolithic applications in favor of more complex microservices architectures that promise to make the overall business more agile.

The fundamental project management issue with repositories such as GitHub is that there is no way to categorize all the project labels that get entered as text. That makes it difficult to monitor and track all the tasks associated with a specific label or even simply browse from one task to the next, Verstaen said. Via Anaxi, project managers can edit their issues and pull requests, which are then synchronized back to their GitHub and Jira projects.

It’s not clear to what degree the lack of sophisticated project management tools has hindered adoption of DevOps in the enterprise. Legacy approaches to application development provide project managers with a rich portfolio of applications that may serve to bias them toward one style of application development over another. But given the pressure organizations are now under to become more agile, project managers need to evolve alongside the rest of IT organization.

Before too long many organizations may also find themselves trying to manage projects spanning multiple repositories. It’s not uncommon for development teams to favor one repository over another. Standardizing on one repository would be preferred, but not every project manager has the political capital inside their organization required to force such a decision. Many projects also now span multiple companies, each with their own repositories, that project managers may find themselves forced to navigate.

At the same time, business leaders are making it clear they want more visibility into the pace at which applications are being developed whenever those applications are expected to generate revenue or improve the overall customer experience. In fact, project managers who can ensure projects are delivered consistently on time and within scope are invariably considered among the most valued of employees.

— Mike Vizard

December 19, 2018
Fighting Deployment Anxiety: 5 Tips from the Pros

You know the feeling: You’ve put in hours of work developing a new feature. It has gone through QA, been tested and passed all stakeholder inspections, and now you’re ready to deploy. Despite your experience and preparation, you have a pit in your stomach. What if something goes wrong and it brings your app to its knees? What if it doesn’t function in your production environment the way it’s supposed to? We’ve all been there. Fortunately, we also have some ways to help.

Electric Cloud CTO Anders Wallgren recently participated on a webinar with Gene Kim, CTO, researcher and co-author of “The Phoenix Project” and “The DevOps Handbook.” Hosted by devopsy.kinsta.cloud Editor in Chief Alan Shimel, the webinar addresses lessons learn from large-scale DevOps transformations, the business value of DevOps and some of the best tips and tricks for fighting deployment anxiety. We pulled out the top five tips and tricks from Kim and Wallgren for making deployment worries a thing of the past.

Tip 1: Automate Your Deployment

A theme throughout the webinar from both Kim and Wallgren was “automation.” One of the big reasons for this is that typically, when you automate your deployments, you’re also automating the diagnosis of problems in those deployments. You can’t always just rely on the exit code of a command-line tool to tell you whether something went right or went wrong. To help keep your deployments healthy, you’ll want to do testing along the way, possibly as a blue-green deployment or a partial deployment. However, if you don’t have automation behind that, it can be difficult to get that accomplished at speed. Without automation, you may start to rely on heroic efforts by individuals—so that every time you are doing a deployment, someone is having to do a figurative tightrope-walk to get everything accomplished. This creates a tough environment for your employees, and can lead to extensive downtime (and lost profits).

Tip 2: Enable Self-Service Deployments to Any Infrastructure

You’re probably wondering why this is a separate topic from automated deployments. That’s because the majority of deployments that occur in a given release pipeline aren’t going into production. Most deployments end up in testing environments (for performance testing, regression testing or just developer testing). It’s also important that you give your engineers the ability to use the same deployment methodology (artifacts, process definition, environment definition, etc.) regardless of the location to where they are deploying. From a cost perspective, allowing QA to test on a local Kubernetes cluster might be more cost-effective for your enterprise than running tests on Amazon Container Service. But, allowing teams to use the same approved automation as part of every deployment—to any location—means a more thoroughly rehearsed and therefore less anxiety-inducing deployment.

The ability to do self-service deployments also gives your teams the ability to move substantially faster when they need to deploy something for testing by avoiding the need to open a ticket and get your Ops teams involved. By allowing self-service deployments, you can avoid the process of running around to find the right person to accomplish the deployment you need to run, and empower your organization to react and build more autonomously across different groups. The result is better-tested and built deployments (resulting in lower deployment stress and fewer errors).

Tip 3: Self-Service Environments

We’re continuing to roll with the theme of automation, but this time we’re talking about self-service environments. More often than not, we’re working with complex distributed apps. This means things such as a containerized microservice application, DBMSs, messaging, key value stores, legacy applications and third-party vendors that we need to integrate with—all things that make our deployments complicated. Being able to consistently provision complex environments is a very important part of being able to successfully recreate a deployment as you promote the application through its life cycle.

It’s important to make sure that your engineers, and in particular, your QA and development engineers, have easy access to environments and that they’re not standing around waiting for access. When you don’t have the ability to get VMs or containers provisioned and configured correctly to receive your application, you run into problems. One of these problems is that your ability to test rapidly just became much more difficult. When you can’t get a near-production quality environment stood up in a few minutes, it means that your bug fix that requires just a few lines of code could potentially take weeks to test. Suddenly you need to requisition a set of VMs to test on (which could take weeks) and another day or two to do the deployment, and only then can you complete your tests. Things become painfully slow. And, when it comes to testing and fixing bugs, slow equals stress.

Tip 4: Artifact Repositories

Want to feel more confident about your releases? Look at your artifact repositories. Use of a shared artifact repository in production environments has been shown to be a good are a really good predictor of deployment success. If you’re not versioning your binaries, and have little insight into where binaries are coming from and how they were built, it can lead to failed deployments.

It may not be easy or simple to get your artifact repositories in line, but it’s a labor that will pay massive dividends in the long term. Electric Cloud worked with a massive online mortgage company that had the challenge of deploying large artifacts (gigabytes) into multiple data centers. To get everything up to speed, it was necessary to transfer those artifacts out of their build and test infrastructure and into their pre-production and production infrastructure. Because of the size of the artifacts and concerns about worldwide availability for the files, Electric Cloud worked with this financial services company to use Amazon S3 as the backing store for the repository server to create a long-term solution that is flexible and scalable.

Tip 5: Security and Auditability

If you work in a regulated industry, already know the heartburn auditability and governance can cause. Security is one of—if not the single—most important aspect of many application delivery pipelines. The reality is, we are just beginning to scratch the surface of the problems we will see the in the future when it comes to infrastructures getting hacked. So what’s our tip? Again, it comes back to automation. At ElectricCloud, there is a saying: Automation is auditing, automation is documentation.

The idea behind this is that by automating your deployment tasks, you are essentially creating a very real and tangible paper trail that shows what you intend to do (the automation definition) and a report of exactly what happened (the automation logs). When you rely on manual deployments, you suddenly take an aspect of repeatability and predictability out of your workflow. At that point, you are forced to report based on people’s spreadsheets, emails and memories. This is one of those things that doesn’t become a big deal until it’s a really big deal, and—to borrow another saying—an ounce of prevention is worth a pound of cure. In the case of auditability and security, being able to retrace your steps because your steps are always the same is a fairly foolproof method to making your audits much more smooth.

To provide a real-world example for how automation can make auditing and security much less painful, one of ElectricCloud’s clients is an aerospace customer with very stringent and demanding security standards. In the past, at the end of each release, it would have a two-week process where everybody had to sit down and compile a list of every single check-in deployed as part of that release. They had to understand where it got built and exactly how it was tested, and then assemble all of that information in a report. It was an extremely time-consuming, but seemingly necessary process. However, by automating many of the steps in the pipeline, the audit response effort went from a two-week process to just a few hours. They accomplished this because 99 percent of the information they needed was in the automation system and was simply scraped as part of process. The task went from manually pulling that data to just getting into it consumable formats.

Summary

By now you’ve certainly seen a theme emerge in our recommendations for reducing the stress of deployments—namely, automate! By putting effort into automation and streamlining your pipeline, you can take what was once a very labor-intensive and sometimes stomach-churning process and make it much more enjoyable. Not only will this save you time and money in the long run, but it will also allow you to focus on building better software, doing more deployments and focusing on the tasks that bring your business and your customers real value.

For more details on how you can relieve your deployment anxiety, and to hear the rest of the discussion focusing on the lessons learned from large-scale enterprise DevOps transformations and the business value of DevOps, watch the full replay.

About the Author / Sam Fell

Sam Fell is the Head of Marketing at Electric Cloud, responsible for driving awareness and demand for our DevOps Release Automation and Acceleration solutions. For 20 years, Sam has helped companies achieve success by marketing, selling, and implementing DevOps Release Automation, IT Change Management and Application Performance Management solutions. Prior to joining Electric Cloud, Sam held leadership roles at BMC, CA, Marimba and Nimsoft. Follow him on Twitter and connect with him on LinkedIn.

July 25, 2017