Summary:

We explain why the flurry of releases in our v6 cycle is actually a positive sign of our transparency around security. Collaborative open source scrutiny helps us quickly strengthen our code, which in some places is more than 2 decades old.

Introduction

If you’ve been following the Revive Adserver project, you may have noticed a quick succession of releases in October and November 2025. Notably, each of these releases contained one or more security improvements. We wanted to shed some light on this, and put this matter into a broader perspective of open source software development and security awareness.

The road to Revive Adserver v6

Work on the new release actually started a long time ago. One of the main objectives was to extend support for the more recent versions of PHP, the programming language that’s at the heart of Revive Adserver. Our previous stable release (v5.5.2, April 2024) was compatible with PHP 7.3 through 8.1, although support for PHP 8.1 was introduced in version 5.4 (back in April 2022). On the internet, 3.5 years is an eternity.

The Revive Adserver project is in the fortunate position that our lead developer, Matteo Beccati, is also a contributor to the PHP project. This means we have a deep understanding of the language’s direction, allowing us to be proactive. For instance, we were able to start work on PHP 8.5 compatibility in early 2025, well ahead of its scheduled release in late 2025, a crucial step for future-proofing the software.

At the same time, we know many users still operate on Linux distributions that aren’t the most recent. Especially in complex, established environments, migrating off of legacy operating systems and older PHP versions isn’t quick or easy. As an open source project with a broad user base, we needed to make sure our efforts supported both our loyal, long-time users, and newcomers who are already on the latest technology.

A bumpy release cycle

In the middle of September 2025, we published a Release Candidate for v6.0.0, aimed at giving our users an opportunity to test drive the new version. We don’t really know how many people actually did that, but no issues were reported on our Github repository. Meanwhile, we worked very closely with the systems team in our parent company Aqua Platform. That gave us an opportunity to do many real life tests and look at many different scenarios. After several weeks of testing, we concluded that there were no major blocking issues, and on October 22, 2025, we publicly released the official Revive Adserver v6.0.0.

Since v6.0.0 included a fix for a low risk security issue, we published a security advisory SA-2025-001 alongside it. This advisory appears to have attracted the attention of the wider security community. The very next day, we were alerted to a newly discovered security issue within v6.0.0. While we can’t speak to the researcher’s timing, the immediate report following the stable release allowed them to validate their finding through our official disclosure channel, HackerOne.

We decided to quickly follow v6.0.0 with a new version 6.0.1 with that security issue fixed. That way, users who were about to update from version 5.5 to version 6.0 had the opportunity to go to v6.0.1 immediately, and skip the affected version altogether. We published version 6.0.1 two days later, on October 24, 2025. And as before, there was a full security advisory SA-2025-002 about it.

Unfortunately (or fortunately, depending on how you look at it), in the next few days several more reports were opened in our security program at HackerOne. A couple of them were dismissed immediately because they were actually non-issues or irrelevant to our code. But after the dust settled, we were left with 10 reports about issues ranging from very low risk to relatively high risk. We began planning the next release, and worked closely with the reporters of the issues on the fixes we proposed.

After another round of intense testing and reviewing, we were able to publish v6.0.2 on November 5, 2025. This release was once again accompanied by a security advisory SA-2025-003. At the time of writing of this blog post, that advisory is still a placeholder page, the full advisory will be posted shortly, giving our users sufficient time to update to the recommended version before the specifics of the issues are publicly available.

Why suddenly so many security issues?

There are many ways to contribute to an open source project like Revive Adserver. Some people take time to carefully document and report bugs that they’ve encountered in our software, or propose new features for future releases. Others dedicate considerable time to supporting their fellow users on our community forums. And again some others are able to help translate the software into dozens of languages. And there’s also a group of people with a particular talent to analyze source code and spot opportunities for security improvements. Ever since 2015 we’ve had a dedicated place on the HackerOne website where people could responsibly report such findings.

The Revive Adserver software has a long and rich history, and many parts of the code are more than 2 decades old. A good portion of the software was developed in a time when security was much less top of mind than it is today. The overall understanding of, and attention for, security in software and systems is much more sophisticated nowadays.

It might seem concerning that there is suddenly a worrying number of newly discovered security issues. However it is our opinion that it is actually a good thing that there is full transparency about such discoveries. The very fact that Revive Adserver is open source software means that anyone can have a good, deep look at it. Some people have been able to find opportunities for security improvements by looking at the code in very different ways from how we see it.

Is open source software less secure than commercial software?

Any open source software comes with bugs and security issues. So does commercial and closed source software. All software is just as likely to be vulnerable, because software developers are human beings that are capable of making mistakes. There is no reason whatsoever that developers of closed source software are less likely to create code with security issues. We just don’t know about it. And even if something is found and fixed, it’s almost never openly disclosed. Just think about all those app updates you get on your phone where the only thing mentioned under “What’s new” is simply “Bug fixes and improvements”.

How we collect security reports

Our project uses HackerOne to collect reports about security findings. In their own words, HackerOne “helps organizations build trust by finding and fixing critical risks before attackers can exploit them.” When someone finds an issue, they can responsibly report it to us via HackerOne, and the entire process from initial report to full disclosure is managed using HackerOne tools and services.

Our reputation for fixing security issues

Our project has a very good track record in both initial triage and responses to newly reported security findings, and a very short turnaround time between discovery and fix release. To put this in context, ever since we opened our vulnerability reporting program on HackerOne in October 2015, we’ve resolved 61 valid reports from 29 community members, and we scored a response efficiency of 100%. We’ve actually had a total of 173 reports, but 112 of those were invalid because they were about systems or software that we do not maintain. For example, people sometimes report issues about our website that they should have reported to WordPress instead.

Our objective is to send a first response to a new report within 1 hour of submission, and we’ve met this target in 93% of cases. Our second objective is to perform an initial triage of a new report within 2 days of submission, and we have a 100% success rate on that target. We aim to resolve new reports within 30 days, yet our median resolution time is less than 13 days.

Once a reported issue makes it into a new release of our software, we always publish a fully transparent security advisory on our website.

In conclusion

Just like our users, we would much prefer that our code (and any other software) does not contain security vulnerabilities. But that’s simply not realistic. The next best option is to have a solid reporting channel, an effective remediation process, and a transparent disclosure policy. We will continue to work with the community of security researchers to make Revive Adserver as secure as possible.

(image credit fidsor)