CVE-2026-43883 is a medium-severity (CVSS 4.2) CWE-639 vulnerability in wwbn/avideo. No vendor fix is recorded yet; mitigation options are listed below.
WWBN AVideo: IDOR in PayPalYPT agreementCancel.json.php Allows Any Authenticated User to Cancel Arbitrary PayPal Subscription Agreements
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-43883 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
wwbn/avideoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
plugin/PayPalYPT/agreementCancel.json.php cancels a PayPal billing agreement using an attacker-supplied agreement parameter without verifying that the authenticated user owns the agreement. A low-privilege authenticated user who learns or obtains another user's PayPal billing agreement ID can silently suspend the victim's recurring subscription, causing revenue loss to the platform and loss of paid service to the victim.
Details
AVideo's PayPalYPT plugin ships two near-duplicate endpoints that cancel a PayPal billing agreement. Only one of them enforces ownership:
-
plugin/PayPalYPT/PayPalAgreementCancel.json.php:19— correctly requires either admin or the agreement's owner:if (!User::isAdmin() && !Subscription::isAgreementFromUser($_POST['agreement_id'], User::getId())) { $obj->msg = "Only the owner can delete his agreement"; die(json_encode($obj)); } -
plugin/PayPalYPT/agreementCancel.json.php:9-26— only checksUser::isLogged()(in fact twice, redundantly) and then calls the cancellation directly:if (!User::isLogged()) { ... die; } // line 9 if (empty($_REQUEST['agreement'])) { ... die; } // line 14 if (!User::isLogged()) { ... die; } // line 19 — duplicate; no ownership check $plugin = AVideoPlugin::loadPluginIfEnabled("PayPalYPT"); $agreement = PayPalYPT::cancelAgreement($_REQUEST['agreement']); // line 26
PayPalYPT::cancelAgreement() at plugin/PayPalYPT/PayPalYPT.php:548-566 resolves the agreement ID against PayPal and calls $createdAgreement->suspend($agreementStateDescriptor, $apiContext) unconditionally — the server does not verify that the logged-in user's users_id matches the owner recorded in PayPalYPT_log (or wherever the agreement was registered):
public static function cancelAgreement($agreement_id)
{
...
$createdAgreement = self::getBillingAgreement($agreement_id);
try {
$createdAgreement->suspend($agreementStateDescriptor, $apiContext);
return Agreement::get($createdAgreement->getId(), $apiContext);
} catch (Exception $ex) {
return false;
}
}
The intended UI caller is subscriptions_list.php:84 which posts the current user's own agreement IDs — but the server accepts any agreement parameter from any logged-in user. Agreement IDs can leak via _error_log entries written in agreementCancel.json.php:34 and webhook.php during normal operation, via PayPal receipt emails, or via other administrative and payment-log screens. No CSRF token is required, but the root defect is missing authorization, not CSRF.
PoC
-
Log in as any low-privilege user (registered subscriber, commenter, free-tier account created via
signUp). -
Obtain the target's PayPal agreement ID (e.g.,
I-ABCD1234XYZ). This may come from server error logs, email receipts, admin/payment screens, or other disclosures. -
Send the request with the victim's agreement ID:
curl -X POST 'https://target.example/plugin/PayPalYPT/agreementCancel.json.php' \ -b 'PHPSESSID=<attacker_session>' \ -d 'agreement=I-ABCD1234XYZ' -
Expected response:
{"error":false,"msg":""}The victim's billing agreement is suspended at PayPal via
Agreement::suspend()(PayPalYPT.php:560). The victim stops being billed; AVideo subsequently reflects the subscription as inactive.
Impact
- Any authenticated user can silently cancel another user's active PayPal recurring billing agreement.
- Revenue disruption for the platform operator — any affected subscribers stop being billed.
- Service disruption for the victim — their paid subscription lapses.
- The defect is purely an authorization gap; the sister endpoint
PayPalAgreementCancel.json.phpdemonstrates that the owner/admin check was intentional for this action but was not applied to this duplicate.
Recommended Fix
Port the ownership check from the sister endpoint into agreementCancel.json.php:
if (!User::isAdmin() && !Subscription::isAgreementFromUser($_REQUEST['agreement'], User::getId())) {
$obj->msg = "Only the owner can cancel this agreement";
die(json_encode($obj));
}
Alternative, preferred remediation: delete the duplicate agreementCancel.json.php entirely and point the cancelAgreement() JS helper in subscriptions_list.php:84 at the already-protected PayPalAgreementCancel.json.php endpoint (sending the expected agreement_id POST field). While patching, also remove the redundant second User::isLogged() branch at line 19.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | wwbn/avideo | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wwbn/avideo, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of wwbn/avideo has shipped for CVE-2026-43883 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-43883 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-43883. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-43883 in your dependencies?
O3 Security finds CVE-2026-43883 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.