In today’s digital-first economy, your brand story lives and breathes through video—from e-commerce product reels to customer testimonials and user-generated content. But what happens when the infrastructure behind that video platform becomes your weakest link?
A newly disclosed vulnerability in a popular open-source PHP platform is a clear reminder: routine vulnerability assessment is not optional. It’s the foundation for protecting both your customers and your brand’s digital identity.
PHP: The Web’s Silent Workhorse and a Key Target
According to BuiltWith, PHP powers over 74% of the internet’s websites, including leading e-commerce platforms like Magento, WooCommerce, and Prestashop. These platforms handle millions in transactions and user data. Their popularity makes them prime targets for open-source security threats, particularly when dependencies and third-party components are not continuously monitored.
A 2024 report from IBM shows the average cost of a data breach now exceeds $4.35 million. But the real damage goes beyond financial loss—customer trust and brand reputation take the biggest hit.
The Exploit: CVE-2025-48732 in AVideo
The latest threat in this category comes from the wwbn/AVideo platform, which serves thousands of streaming and video hosting applications built in PHP.
The flaw allows attackers to bypass upload restrictions and execute arbitrary code on the server.
The root cause? Improper handling of PHP archive files, which aren’t adequately blocked or validated.
This is a classic example of supply chain exposure through unpatched third-party libraries. Without proactive open-source vulnerability scanning, affected organisations remain blind to threats lurking in their dependencies.
We regularly analyse open source projects to identify security risks. The image below shows a short summary of the open source software library WWBN/AVideo, which has been found to have critical vulnerabilities.
Why Continuous Vulnerability Assessment Matters
This isn’t just about one vulnerability. It’s a wake-up call for all businesses using open-source frameworks to:
✅ Implement automated vulnerability assessment tools that scan your software supply chain in real-time ✅ Track emerging CVEs across your entire application stack ✅ Flag unsafe libraries and automatically suggest fixes ✅ Maintain a software bill of materials (SBOM) to understand your exposure footprint ✅ Integrate patching into your CI/CD pipeline for faster remediation
If your video platform or customer-facing application relies on AVideo, or any PHP component, you need a continuous security strategy to detect and resolve vulnerabilities before attackers strike.
Secure Your Platform Before It’s Compromised
At Meterian, we help teams detect and remediate vulnerabilities across their software supply chain through real-time open-source monitoring, automated remediation, and SBOM-driven visibility.
Want to know if your app is exposed to CVE-2025-48732?
Get a full breakdown of the AVideo vulnerability, exploit risks, and how to patch it now. 👉 Download our Security Report
Don’t wait to become the next headline. Stay ahead with intelligent, AI-powered vulnerability assessment.
Attacks through open source are growing year on year, so companies cannot rely only on periodic pen testing. The code needs to be scanned on a daily basis during the lifecycle of the application’s development stages, and continue to do so once an application is deployed.
Modern software development in fact heavily relies on open-source components: they accelerate development, reduce costs, and provide access to well-tested, community-maintained code. Understanding the composition of their software products is crucial for companies producing applications, as it helps manage and secure the significant portion of their codebase that originates from open-source projects.
Checking open-source components in software development is crucial for at least three reasons: let’s have a closer look and clarify the problems.
Security Risks
The code of open-source components is always publicly available and it is a natural target for hackers. Each day, more than 50 new vulnerabilities are discovered in open-source components and, if not identified and managed, they can be exploited, leading to security breaches.
the iCloud and Minecraft hack (2021): Log4j vulnerability (CVE-2021-44228)
All these hacks were performed using a vulnerability in an open-source component: nothing was wrong with the code written by the respective developers.
How common are vulnerabilities? See, in this sample, the growth of vulnerabilities in the .NET open-source ecosystem:
Please note that this is a restricted view that matches exclusively only vulnerabilities affecting opensource components specific to the .NET ecosystem. Across all ecosystems, more than 100,000 vulnerabilities affecting open-source components are recorded.
The risks are real. If you want to learn more you can also read our blog here.
License compliance
Open-source components come with various licenses, each with specific requirements and restrictions. Failing to comply with these licenses can lead to legal issues, including copyright infringement claims.
Among all those, let’s not forget TruthSocial, the famous Twitter clone created by the Trump Media & Technology Group, was found to be in breach of an OSS license and had to disclose its source code publicly.
The risks are real. If you want to learn more you can also read our blog here.
Quality and reliability
While open-source software can be of high quality, this varies significantly, and some components might be abandoned or poorly maintained. Using such components can pose risks to the project’s stability and reliability.
Here introducing you Swashbuckle, a popular .NET project that has been abandoned by his creator for a more interesting adventures and now lays unmaintained and without an owner. It was last updated 6 (six) years ago.
Let’s also have a look at Lazy, another popular NodeJS component that was last updated 11 (eleven) years ago. While it’s a small library with a limited attach surface, why would you like to have this in your application? Software does not age like fine wine, unfortunately.
This is an example of two commonly used opensource components that have not been updated in years, a very long time in software development. Those components are basically not maintained anymore: if a problem is found, it won’t be fixed. If a vulnerability is there, nobody will know about it (apart from the occasional hacker, of course)
How Meterian SCA helps solve the challenge
Meterian offers a comprehensive application security platform designed to enhance the security posture, compliance adherence, and overall quality of software projects. This platform provides in-depth analysis and automation capabilities, empowering organisations to effectively manage open-source and third-party libraries throughout their software development lifecycle. Through its robust features, Meterian enables organisations to identify and mitigate vulnerabilities, ensure compliance with relevant regulations and standards, and maintain a high level of software quality.
Meterian is unique compared to its competitors because of various characteristics, let’s explore them
Supports the largest number of ecosystems If you are using a legacy technology like Perl, focus on data science using Jupyter Notebooks, build video games with Unity, or build ultra-fast micro-services with Rust, you deserve the best protection available. Meterian supports a wide range of languages and ecosystems, and if your platform is not there, we will be happy to support it for you.
Easy to to deploy on premises or dedicated cloud In the SaaS industry, the requirement for a dedicated single-tenant instance or an on-premises installation may be driven by specific business needs, such as tight security, data sovereignty, and geo-location considerations. Meterian can easily provide a single-tenant environment, either on-cloud or on-prem, and offers also a range of air-gapped solutions for extreme secure environments.
Comprehensive vulnerability database Meterian’s vulnerability database not only boasts a broader coverage than any of its competitors but is also updated daily through a fully automated system that integrates numerous OSINT sources and Meterian’s specially curated databases, including AI-generated advisories directly from the analysis of open-source repositories. This automated process outpaces manual entry methods, ensuring we maintain a competitive edge through faster and more efficient updates, a key differentiation in our service offering.
Superior customer support Speed, quality of responses, customer obsession, won deals because of this. We have a unique culture where the concept of “support” does not really exist, as all engineers are constantly working with customers. We want to be obsessed with customers, solve their problems quickly and effectively. Every customer support query is directly handled by engineers and is given priority in our backlog. This approach guarantees that our product evolves in response to real-world feedback, while also maintaining the highest level of customer satisfaction.
What next?
Don’t just take our word for it – experience the benefits for yourself. We invite you to schedule a demo to see how our solution can make a difference in your organisation’s security posture. Our team of experts is ready to guide you through the features and show you how it can address your specific security challenges. Take the first step towards a more secure future – reach out today and discover how Meterian can elevate your cybersecurity strategy.
We are sure many of you have been hearing about SBOMs. Nowadays, software include some components with code written by your own developers, but 80-90% of the code is typically from third-party developers. How can you know who produced what and when it absolutely needs to be replaced? Since Meterian has been managing SBOMs for awhile, we’re happy to share our know-how so you can consider a comprehensive strategy to manage your open source software supply chain.
SBOM is an acronym that means Software Bill Of Materials. The concept originates from the manufacturing industry, where a bill of materials lists dependent components in machinery. A SBOM lists all third-party components present in your application. A good SBOM also lists the licences used by each component and, when possible, the specific copyright attribution. An excellent SBOM can also provide further information, such as possible relationships between those components to better understand any supply chain risk. You may have encountered SBOMs in the past, known as “third party notice” documents created to manage legal requirements, such as the one in the image below.
However, modern SBOMs are “machine-readable”. They follow a strict specification that can be understood by a computer.
What machine-readable formats are used to publish SBOMs?
The most commonly used formats to define a SBOM are:
CycloneDX, a lightweight open-source standard designed for use in application security context and supply chain component analysis. This originated from within the OWASP community.
SPDX, an open source format with origins in the Linux Foundation, slightly more complex, and recently approved as ISO/IEC standard in version 2.2.1 as ISO IEC 5962:2021.
SWID, another ISO/IEC industry standard used by various commercial software publishers.
All these formats support a variety of use cases, but the first two (CycloneDX and SPDX) are the most versatile. Due to SPDX’s complexity, we think CycloneDX has an edge at this time, but only time can tell which of these formats will be the winner. To learn more about these formats you can also read the official NTIA publication, which drills down into the matter.
Why are SBOMs important? And how are they useful?
As a consumer of software, the main reason why you want to have access to the SBOMs of the systems you are using is to manage risks. When a very commonly used software component becomes vulnerable: how do you know what you need to patch and which subsystems are at risk? This is exactly what happened with the recent Log4Shell debacle. The logging library called Log4j, was suddenly exploitable with a very simple and repeatable attack. How do you know where it is? Which one of the systems you are using is suddenly at risk? With a correctly managed archive of SBOMs, getting this information reduces to a very simple lookup task. Without it, it can be a real nuisance —a time consuming information hunt that disrupts everyone’s work flow.
As a producer of software, instead, you want to preserve and maintain an archive of all the SBOMs of the system you produce so that you can create and distribute timely patches to your customers. Having a systematic and comprehensive analysis of your most commonly used software packages would be useful indeed. Some companies were very fast in releasing patches to their customers, while others were extremely slow, mostly because they did not have the information. You probably want to be in the first group of companies 🙂
Governments are also mandating the need for use of SBOMs, realising that software security needs to be regulated. The U.S. Executive Order 14028 that mandates all federal agencies to require SBOMs from their suppliers. This not only impacts the companies that have direct sales to the US government but also their own software suppliers. As so many systems and devices have been connecting to the Internet to send and receive information, consequently our digital world relies on a software supply chain. This “ripple effect” will be significant for many industries.
Very carefully :), because an SBOM contains the full list of the “ingredients” of your system or application. While open-source projects happily share this information to the world, the same does not apply to private companies. In fact, a malicious actor that gets hold of the SBOM of your system can then check if you are using any vulnerable components. There are public vulnerability databases, such as the NVD, which are very popular. Someone can simply browse in there and compose a list of possible attacks, try them, and maybe get lucky. Probably 9 out of 10 vulnerabilities affecting components in your system won’t be exploitable, but having the ability to go through the whole list, certainly makes the task of finding an exploit much easier.
There’s no need to keep SBOMs a complete secret, however, as long as a few simple principles are kept in check:
SBOMs need to be shared securely,
they need to be accessed only by the authorised parties, across organisational boundaries, and
they should not be tampered with.
In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.
Why bother with SBOMs now?
In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties. In our hyper connected world, comprehensive coverage of components is important for preventative strategies and threat detection in supply chain attacks. Therefore, implementing SBOM management proactively now will be worth something to your organisation when the next critical vulnerability appears and stand your organisation in good stead. All good collections are worth organising. How valuable is your collection of software?
The need for SBOMs is already high. Level up your open source software security and implement this requirement. Check out the SBOM capabilities in Meterian-X platform’s approach to DevSecOps.
As it’s a requirement that all open source projects are released under at least one open source license, they hold a great deal of influence in how said open source code is used and re-distributed by others. Whilst some licenses can be difficult to make head or tail of due to complicated non-developer language, there are some more relaxed licenses that take the opportunity to have some fun with their requirements. So, to save you doing it, we have assembled our top 5 all time quirky open source licenses to look out for:
The Beerware License
Written by Danish software developer Poul-Henning Kamp, this license states that if the user thinks the stuff they reuse is worth it they must buy the creator a beer in return. The license’s original notation can be found here. Kamp states his reasoning for the Beerware license is an act of defiance against ‘lawyers trying to interpret freedom’, believing that free open source code should remain free regardless of how much profit is made through its use. Since the requirement is optional, based on the contingency that the user believes the code is ‘worth it’, this license falls under the category of ‘CopyRight only’ licenses. If the requirement were mandatory, the license would be classed as ‘non-free’, and Kamp would most likely be drunk a lot of the time.
The Chicken Dance License
Otherwise known as the CDL, this license requires employees affiliated with organisations using the open source code to perform ‘The Chicken Dance’ for varying amounts of time, depending on how many units are distributed. The license was created by Andrew Harris with the goal of making “intellectual property far more entertaining to deal with”. Similarly to Kamp, Harries includes himself in wanting fewer lawyers in software – suggesting that the motive behind this wacky license holds strong roots in open source principles of open collaboration. The ‘Chicken Dance’ in question can be found here, but if you can’t master it don’t worry- the license states that moving in a chicken like manor is sufficient.
The Don’t Ask Me About It License
Perhaps the most simple of the licenses included in the blog, this license simply requests that users do not pester the creator with any issues they may be having with the file. The nod to lack of responsibility is admirable, there is something to be said for wanting to lead a quiet life post software development.
The Hot Potato License
This license states that ‘all rights are reserved by the last person to commit a change to this repository’. Thus, the rights are passed on from person to person infinitely- like a game of hot potato. However, to avoid anyone interrupting this game of hot potato, users are prohibited from making drastic changes to the repository that would do so. It’s a nice touch from the creator to give us all the opportunity to control the rights of such a well known open source license at least once in our life
The Do What The F*** You Want License
The Do What The F*** You Want License is a ‘very permissive’ license that can be taken as a direct stand against the principle of licencing software in general. Whilst playing by the rules of licencing, this license intends to be a free pass for distribution without any constraints. However, in the attempt of being so liberal, this license actually poses an issue for some major corporations. For example, Google finds the license too unclear to use confidently. As a result, they have banned the use of components under this license completely. However, if you like the look of this license don’t let Google scare you off, wtfpl.net offers guidance on how to make the most of it.
Whilst there is a funny side to open source licensing, failure to stay on top of your business’s license compliance management could be detrimental. A strong defence of these risks, as well as efficient software composition analysis tools will help manage the use of open source in your code base and avoid hefty fines and diminished customer relations. In this way, legal due diligence is an important step in agile development as it allows to ‘push forward’ and remediate any legal obstacles blocking a decision from being made. To read more about cyber due diligence, check out our past blog.
The right open source license is necessary to protect your intellectual property and an important factor in maintaining license compliance management. As well as this, open source licensing underpins the essence of open source values in facilitating open redistribution. The integration of license compliance management into your CI/CD pipeline is just another way of optimizing the efficiency of your software supply chain. The best license for you will be shaped by your reason for creating code and your goals for redistribution. Use our introductory guide to decide which is best for you. Licenses and legal terminology are that of a very different world than what developers are used to. Because of this, we have organised our guide into developer persona categories. Simply pick the Dev that aligns most closely with yourself to learn more.
Devs working within a community:
If you are collaborating with an existing community or project, the best option for you is to align with the community you are a part of by adopting the project’s existing license. This can be found under the ‘license’ or ‘copying’ file of a project. If this fails, simply contact the maintainers of your community for clarification. As the licensing decision has already been made for you, you can spend less time on legalities and more time on software innovation- lucky you.
Devs not looking to overcomplicate:
The MIT license is perfect for devs that want to keep things straightforward. It is relaxed in that redistribution requires little to no control criteria other than the continuation of copyright and licensing details. The material that falls under this license is able to be used for both commercial and private use, as long as a copy of the license and copyright notice is included in any instances of modification or distribution. However, when using this license you should be aware that limitation of liability is included. As well as this, there is no warranty provided with this license.
Devs that care about sharing improvements:
The GNU General Public License v3.0 allows you to copy, distribute and modify projects under the condition you note all modifications and dates of modification in the source files. All modifications made to GPL-license code must also be made available under the GPL with installation instructions for future devs. This license forbids users from sub-licensing, although it provides software that does have the right to run and distribute the code. Users should be aware that this license includes a limitation of liability, meaning that the owner cannot be charged for damages associated with code using this license.
We hope this quick read has shed some light on the world of license compliance management. Whilst it may be confusing at first, it is worth taking the time to pick the right license for you and your project to best publish your software and display your innovation. For more information on potential risks associated with license compliance, see our past blog: ‘How the wrong license can harm your business’.
