Onyx Digital Intelligence.

Bitdefender, Held To Its Own Words

Updated 25 June 2026: new findings added below confirming the self-disable and Double Hop exposure both survived the most recent app update, and identifying why the protection-disabled alert arrives silent.

An #OnyxAudit account: a reproducible VPN flaw, a written claim that it was fixed, a written retraction the next day, and the gap between what a security company sells and what its own documents say.

A note on method

This is an #OnyxAudit piece. Every claim below is one of three things: something I reproduced and captured, something Bitdefender stated in writing to me, or something published in Bitdefender's own documents and public records. Where a point is my analysis, I say so. Where something is probable but not confirmed, I mark it probable and do not dress it as proof.

I found a reproducible flaw in a product I pay for. I reported it through the vendor's process. I supplied video, device data, and replication steps. Over the weeks that followed, Bitdefender told me in writing that the flaw was fixed in the latest version, and then, the next day, told me in writing that there had never been a defect to fix. Both statements came from the same engineer on the same ticket. This is the record.

Three tiers are used throughout:

1. The reversal, in their own words

On 29 May 2026, at 11:09 PM, a Bitdefender Technical Support Engineer wrote to me, on ticket #DHCSKRSKGW4RAHCN6SJPG2:

"The reported situation concerning the VPN has been fixed in the latest version. Please make sure that you have updated Bitdefender VPN to the latest available version."

Roughly twenty-six hours later, on 30 May 2026 at 01:14, the same engineer, on the same ticket, wrote:

"I would like to sincerely apologize for the previous information provided, where I mentioned that the issue concerning the VPN had been fixed. After further verification, it appears that there was actually no defect to correct."

"This has been reviewed internally and confirmed as expected behavior based on how the VPN connection process works, particularly within the constraints of the Android system."

A fix announced on a Friday night was a non-defect by Saturday morning. The product was either patched or it was working as designed. It cannot have been both, and Bitdefender stated both, in writing, a day apart. Everything that follows is detail. This is the center.

2. What the flaw is

I run leak tests on the tools I use. I use no other VPN on the device.

Bitdefender VPN on Android exposes the real IP address during a manual server switch in a Double Hop configuration. On Android, the operating system permits only one active VPN interface at a time. Bitdefender's in-app Kill Switch is a local blocking interface, described by their own support as a "no-route" VPN that drops traffic when the real tunnel is down. When a user manually switches servers in Double Hop, that blocking interface is torn down before the new tunnel is negotiated. During the gap, traffic leaves outside the tunnel and the real IP is exposed.

I reproduced this on a Samsung Galaxy A56 5G, OpenVPN over UDP, Scramble enabled, switching between Double Hop routes. At the 0:38 mark of the screen recording I supplied, the real South African IP (REDACTED) and the Telkom DNS resolver are visible while the app sits in the "Connecting" state. The leak occurs with Scramble on, which means the failure is not the obfuscation layer. It is the Kill Switch not holding during the handshake.

This is not a claim that the VPN fails in normal use. It is a specific, reproducible condition under which the protection the user is relying on is not in effect. The condition sits inside Double Hop, which Bitdefender markets, in its own words, as the option "for those who take no chances in securing their privacy." The exposure is in the tier sold to the users who care most.

3. Timeline

Dates and quotes are from the email thread and device captures.

A Technical Support Engineer asked for detail on "a DNS leak only when Double Hop is enabled" and stated they would "determine whether this is a configuration issue, a platform-specific limitation, or something else." (Documented.) A Commercial Support Representative separately wrote that the matter had been "escalated to our dedicated technical team for thorough investigation and resolution." (Documented.)

I submitted the full vulnerability report, subject line "I am reporting a reproducible security vulnerability within the Bitdefender VPN Android application," with the screen recording and device details. The engineer replied: "Thank you for the extensive technical details and supporting evidence you provided. We have shared this information with our development team, who are now investigating the reported behavior to identify the cause." (Documented.)

Sustained exchange. I disclosed device identifiers, configuration, and personally identifying information through their secure portal at their request. Their words described escalation to an engineering team and copied a research team on correspondence. The word "partnership" was used. (Documented.)

My emails to security-research@bitdefender.com began bouncing with error 554 5.4.14, hop count exceeded. The vendor's own security-research channel was not delivering. (Documented, captured.)

I wrote that the security-research address had been bouncing since 16 May, that I had received no response to my last two emails, and that two issues remained open: the VPN disclosure (I had requested the formal disclosure link and patch timeline, no response) and the modules self-disabling without prompt. (Documented.)

The engineer told me to stop emailing security-research@bitdefender.com because it "is not meant for support situations," and stated the VPN issue "has been fixed in the latest version." (Documented.)

The same engineer retracted the fix and stated "there was actually no defect to correct," reclassifying the behavior as expected. (Documented.)

I replied under the subject line "UNRESOLVED: Security Escalation Request." (Documented.)

Bitdefender wrote that it was again clarifying with the testing and development team and asked me to re-upload the video. (Documented.)

Bitdefender delivered its final position, quoted in full below. (Documented.)

4. The final position, against the marketing

Bitdefender's final written position, 18 June 2026, verbatim:

"Your reproduction is accurate and the behavior is real."

"On Android, the OS allows only one active VPN interface at a time. That means when you manually switch servers, the blocking interface must be torn down before the new tunnel can be negotiated, and the renegotiation window (typically 1 to 2 s) is the gap you observed."

"It is not something we consider an acceptable operating posture, it is a limitation we document and that we mitigate by recommending the OS-level Always-On VPN with 'Block connections without VPN', which uses Android's own enforcement at the network stack layer and does not have this teardown gap during normal reconnects."

The recommended fix is to stop relying on the in-app Kill Switch and use Android's own feature instead. The protection is the operating system. The product feature the marketing sells is the thing they tell you to route around.

Here is what the marketing says, verbatim from the Google Play listing (app version 2.3.2.173, updated 27 April 2026):

"Slip into your digital invisibility cloak. Private, Secure, Ultra-Fast."

"Bitdefender VPN hides your online activity and gives you full control over your digital privacy. Enjoy unrestricted internet access, safely and anonymously."

"Double-hop adds an extra layer of obfuscation for those who take no chances in securing their privacy."

The product sold for taking no chances has a documented one-to-two-second window, confirmed by its maker, where the real IP is exposed. That window is the moment a user switching servers is least protected, and it is the moment the marketing copy addresses directly. A reader doing sensitive banking, password work, or browsing they believe is anonymous is exposed in the exact configuration sold to them as the safest.

5. The infrastructure

Built from primary registration data and Bitdefender's own privacy policy.

I connected the VPN to a Finland server. The app reported my IP as "Hidden." I looked up the exit IP it assigned.

The VPN exits through infrastructure operated by NetProtect, the corporate group that owns IPVanish, and Bitdefender's own policy names IPVanish as the processor. The routing data and the policy text arrive at the same place independently. I do not claim the product is a white-label resale of IPVanish. That is probable, not confirmed, and stays there.

Now the same Section 7.3 also states: "We do not store any details regarding your location or online activity nor do we share them with other entities." And Bitdefender's own Google Play Data safety section, captured 18 June 2026, states under the heading "No data shared with third parties": "The developer says that this app doesn't share user data with other companies or organisations."

A separate company handles the traffic. The store page says no data is shared with other companies. Data-protection law distinguishes a processor acting on instructions from a "share," and that distinction is real and available to Bitdefender. It is not available to the user reading "anonymously" and "no data shared" on the store page, who is told nothing about IPVanish.

On the same Data safety panel, Bitdefender declares the VPN collects "Device or other IDs" and "App interactions" for "Analytics," alongside email address, crash logs, and diagnostics. (Documented, captured.) The product sold for browsing "anonymously" declares, in its own listing, that it collects device identifiers and app-interaction data for analytics.

One piece of provider history, attributed and not laid at Bitdefender's door. Under prior ownership in 2016, IPVanish handed user connection logs to United States Homeland Security Investigations despite a zero-logs policy at the time. (Reported, from the court affidavit, via TorrentFreak and CyberInsider.) This predates Ziff Davis ownership. If you are trusting an infrastructure operator with your traffic, its record is part of the decision.

6. The mobile product

The account does not stop at the VPN.

The scanner calls coursework malware.

My device Activity Log records legitimate Coursera assessment files, hosted on coursera-assessments.s3.amazonaws.com, labelled "Infected has been detected." These are graded assessment files from a Google career certificate. The same files were flagged repeatedly across separate sessions. When I raised it, Bitdefender said the problem was fixed and gave no detail beyond that the threat-detection system had not been updated to include or exclude some results. (Documented, captured. The "Infected" label is theirs. That the files are benign coursework is my characterization, stated as such.) A security product that flags a student's graded assignments as malware trains that student to dismiss its alerts, which is the opposite of what the product is for.

The protection layers switch themselves off.

Web Protection, text protection, and ScamGuard self-disable without notification, leaving the device unprotected with no prompt to the user. I reported this in writing on 27 May 2026, and it predates the One UI 8.5 update. (Documented.)

Bitdefender's response attributed it partly to a separate open issue and partly to Android battery optimization disabling modules that use the Accessibility permission, citing the community site dontkillmyapp.com. (Documented.) The consequence stands regardless of cause: the features a user pays for to detect threats in their apps, messages, and browsing are the features that quietly turn off, and the product does not tell the user it has stopped protecting them.

The product logs in the background on demand.

During a support interaction the app displayed: "Logging is now active. We're collecting technical data in the background for the next hour." (Documented, captured.) This is diagnostic logging triggered by support, not evidence of covert always-on collection, and I do not claim it is. What I can document is that it ran in the early hours of the morning. What the privacy policy documents, in Section 2.2, is the breadth of what "technical data" covers: IP and MAC address, identifiers for a device, user, file, folder, app, and URL, and for products that handle email, the sender, recipient, subject, and attachment. That is the data a "Private, Secure" product is authorized by its own policy to process.

The policy hides its processors in one section and names them in another.

Section 3 of the privacy policy states that "the specific information regarding the name and details for each processor used will be provided only to competent authorities." Chapter 7 of the same document then names them: IPVanish, Constella, Twilio, Sontiq. (Documented, both from Version 10.3.) The document withholds processor identities as a stated rule and discloses them on the next pages.

Mobile-security data feeds third-party AI training.

Section 7.1.2 states that collected Scam Protection and Chat Protection data "may be processed using AI tools and models provided by third-party providers" and that "anonymized collected data may also be used for AI training purposes." (Documented.) The policy frames this as opt-in and anonymized. A buyer of a privacy product is entitled to know their security data, even anonymized, is routed to outside parties with their own privacy practices for model training, and it is not stated anywhere in the marketing.

The self-disable survives the update, and the silence is now explained. On 23 June 2026, after an app update (version 3.3.311.2566), Web Protection, Chat Protection, and App Anomaly Detection were found disabled again, hands-off. Bitdefender's own notification fired: "Protection features have been disabled by the system," timestamped 18:38. There was no corresponding Activity Log entry; the last entry before it was a routine scan over an hour earlier. The notification arrived with no sound and no vibration despite the relevant channel being confirmed at full volume and vibrate. (Documented.) Checked directly against Settings > Notification

History, not inferred:

Bitdefender generated 206 notifications in the surrounding window, the large majority routine "Scanning in progress" messages repeating dozens of times within single minutes. The disable alert sits inside that same notification stream, not a separate channel with its own settings. The volume of routine notification traffic is what causes the one alert that matters to inherit the same silent, non-lead treatment as the noise around it. (Documented.) This reproduced a second time on 24 June, an independent live occurrence of the identical pattern. Retested the Double Hop exposure after the 24 June update, on the current build.

It still leaks. Two independent test rounds in one session, both confirmed via dnsleaktest.com: a South African ISP's DNS resolvers present during Iceland-to-Finland and Switzerland-to-Finland switches, while the app displayed "Secured connection" throughout.

Android's OS-level Always-On VPN was active during testing; "Block Connections Without VPN" was not, because Bitdefender's own setup documentation requires that setting be disabled for split tunneling to function. The mitigation recommended in writing on 18 June requires a setting their own product instructs users to disable for normal use of another feature. (Documented.)

For clarity:

An earlier test showed Android's own enforcement failing once. That does not reproduce on the current build, post-One UI 8.5 security updates, and is not part of this finding. The OS-level mechanism is confirmed functional. This entry concerns Bitdefender's product design, not Android's.

Checked against primary court records and SEC filings, not summaries. Stated without inflation.

DiLorenzo v. Bitdefender. A California class action over Bitdefender's automatic renewal billing, Superior Court of California, County of San Diego, Case No. 37-2019-00066655-CU-BT-CTL. Settled for a principal amount of 925,000 US dollars, class period 16 December 2015 to 16 September 2020, on allegations under California's Automatic Renewal Law. (Documented, from the settlement agreement and administrator records.) Bitdefender paid when a consumer billing practice was challenged in court. I opened my own dealings with them this year over a duplicate charge.

Finjan v. Bitdefender. A patent case, Northern District of California, Case No. 5:17-cv-04790, filed 16 August 2017, four patents. The litigation ran over two years. In February 2019 the court issued a claim construction order adopting the majority of Finjan's proposed constructions. In January 2020 Bitdefender took a paid license and paid Finjan 3.8 million US dollars. (Documented, from Finjan's SEC filings.) A patent matter, weighted as such.

Patent-assertion suits. Bitdefender has been named by patent-assertion entities (AttestWave, 2025; PacSec3, filed June 2025) in suits that ended with no finding against it. Bitdefender is the defendant who did nothing wrong, and I draw no adverse inference. (AttestWave dismissal documented. PacSec3 disposition probable, not confirmed, pending a docket pull.)

What is not there. No United States Federal Trade Commission action against Bitdefender. No state Attorney General action. No other consumer class action beyond the billing case. No South African enforcement action. Absence of a public record is not proof none exists, and I imply no findings that are not there. (Documented negative finding.)

8. The double standard

Bitdefender knows precisely how to write demanding terms when it is the party being protected.

From Bitdefender's own General Terms and Conditions for Providers and its Compliance, Confidentiality and Information Security exhibit, the obligations it places on the businesses it works with (Documented, from the contract documents):

That is a precise accountability framework, drafted in Bitdefender's favor, demanded of its commercial counterparts.

The individual who reported a reproducible flaw in their consumer product, supplied video and replication steps at no charge, disclosed personally identifying information at their request, and asked for a disclosure link and a patch timeline, got this: a bouncing security-research address, weeks of silence, a reprimand for using the channel that was bouncing, a written claim the flaw was fixed, a written retraction the next day, and a final position that the flaw is intended and should be worked around using Android's own feature.

Bitdefender demands 24-hour breach notification from its partners. It took weeks to give me a straight answer, and the straight answer reversed itself inside a day. The reader can measure the distance.

9. The South African dimension

I am a South African data subject. Bitdefender processed my personal information through this disclosure: device data, technical logs, support correspondence, and the personally identifying information I supplied at their request.

South Africa's Protection of Personal Information Act applies to the personal information of people in South Africa, including when processed by a foreign-headquartered company. Its conditions include purpose limitation, data minimisation, security safeguards, transparency, and accountability. (Documented, statutory.) As a data subject I have recourse to the Information Regulator that an overseas critic of a global vendor does not.

South Africa's first POPIA fine, a 5 million Rand penalty against the Department of Justice in 2023, concerned a failure to maintain renewed security-software licences, including antivirus and intrusion detection. (Reported, from the Information Regulator's public statements.) The regulator treats security-software accountability as within its remit. I found no POPIA action against Bitdefender. (Documented negative finding.) I raise the jurisdiction because it is mine, not because an action exists.

10. What I am asking

Put to Bitdefender directly:

Is the one-to-two-second real-IP exposure during Double Hop server switches present in the current shipping Android version, or was it changed in a later build. On 29 May an engineer told me it was fixed in the latest version. On 30 May the same engineer told me there was no defect to fix. On 18 June the position was that it is an intended, documented limitation. Those three statements cannot all describe the same build. I want one answer on the record.

Are the repeated Malware Scanner detections on legitimate Coursera files confirmed false positives, and how are they being handled.

Why do Web Protection, ScamGuard, and App Anomaly detection disable themselves without notifying the user, leaving the device unprotected. The features sold to detect anomalies in apps, messages, and browsing are the features that silently switch off.

If the exposure is intended and will not be changed, users are entitled to know that the in-app Kill Switch is documented by its own maker to permit brief real-IP exposure during Double Hop transitions, and that the protection Bitdefender recommends is the operating system's feature, not the product's.

Why does Block Connections Without VPN, the exact setting recommended in writing as the fix for the Double Hop exposure, need to be disabled for Bitdefender's own split tunneling feature to work.

Users cannot have both the recommended protection and the advertised feature active at the same time, and nothing in the marketing discloses that trade-off.

11. Conclusion

A reproducible real-IP exposure in the configuration sold for taking no chances. A written claim that it was fixed, retracted the next day as never having been a defect. A third-party processor named in the company's own policy beside a store-page claim that no data is shared. A scanner that flags a student's coursework as malware. Protection modules that switch themselves off in silence. Partner contracts that demand a standard of accountability the company did not meet for a documented disclosure.

Every item is a documented fact or a labelled analysis. The conclusion is the reader's. Replicate the claim. Read the documents. Reach your own verdict.

Built under the #OnyxAudit method: Replicate. Document. Disclose. Punch at systems, not people. State facts, let readers conclude.

Onyx Digital Intelligence @BaximusCyber85 / onyxdigitalintelligence85@protonmail.com