CVEs · Issue #14576 · rustdesk/rustdesk

Bug Description Is there a reason none of these CVEs are being addressed? CVE-2026-3598: https://www.cve.org/CVERecord?id=CVE-2026-3598 CVE-2026-30783: https://www.cve.org/CVERecord?id=CVE-2026-307...

GitHub

We don't need to hack your AI Agent to hack your AI Agent …and we don't need an AI agent for that either :)

Via a large enterprise's AI assistant, we obtained access to several million Entra identities and all chat logs including attachments — no prompt injection or model tricks required.

For all we know, the poor agent was not at fault and may not have even been able to witness what was happening.

https://srlabs.de/blog/hacking-ai-agent

#AI #AIhacking #VulnerabilityDisclosure #ResponsibleDisclosure

We don't need to hack your AI Agent to hack your AI Agent - SRLabs Research

We strolled through an enterprise AI assistant's backend, helped ourselves to full application takeover and access to every chat log, and had a Microsoft Entra ID dump for dessert — no prompt injection, no model tricks, no AI expertise required.

SRLabs

Responsible Disclosure: o que fazer quando você acha um zero-day

Você sabe o que é responsible disclosure e por que ele é ESSENCIAL contra zero-days? 👇

• O que é:
- Responsible disclosure (divulgação responsável) = agir com ética: avisar a empresa antes de expor a vulnerabilidade.

• Passo a passo prático:
- 1️⃣ Você encontra uma vulnerabilidade (zero-day)
- 2️⃣ Contata a empresa em privado e...

#segurança #cybersecurity #ethicalhacking #responsibledisclosure #zeroday #infosec #MorningCrypto

Habe heute meinen ersten Responsible Disclosure Report eingereicht 🛡️
CVSS ~5.4, großes deutsches Unternehmen. Bin ein bisschen stolz.
Details gibt's erst nach dem Patch – so gehört sich das.
#ResponsibleDisclosure #InfoSec #CyberSecurity

🔐 Public disclosure: CVE-2025-69690 & CVE-2025-69691
Two authenticated RCE vulnerabilities in Netgate pfSense CE:

CVE-2025-69690 (CVSS 8.8): Unsafe deserialization
→ root RCE via backup restore (pfSense 2.7.2)
CVE-2025-69691 (CVSS 9.9): XMLRPC exec_php
→ root RCE via default credentials (pfSense 2.8.0)

Vendor notified Dec 2, 2025. Acknowledged, no patch planned.
Responsible disclosure followed throughout.

Full write-up: https://github.com/privlabs/CVE-2025-69690-CVE-2025-69691

#CVE #pfSense #InfoSec #RCE #SecurityResearch
#ResponsibleDisclosure

For researchers and those trying to disclose incidents responsibly or get help:

There is an international organization called FIRST.

From the FIRST Teams website:

"This is a list of the contact information for incident response teams participating in FIRST, the Forum of Incident Response and Security Teams. The teams are responsible for providing FIRST with their latest contact information for this page. The list is alphabetized by team name. All telephone numbers are preceded with the appropriate country code."

There are 829 teams listed. Some are government CERT teams, some are corporate incident response teams.

You might want to bookmark the site to speed up your attempt to contact these teams:

https://www.first.org/members/teams/#

#responsibledisclosure #incidentresponse #CERT

FIRST Teams

Contact information for incident response teams participating in FIRST, the Forum of Incident Response and Security Teams.

FIRST — Forum of Incident Response and Security Teams

I once talked about bug bounty platforms and warned the community about them.

There are deeper issues with these platforms:

https://www.linkedin.com/pulse/transparency-vs-silence-advisories-dont-exist-systems-johannes-greil-ufzpf/

Platforms are paid by vendors, so they listen to vendors. A lot of these vendors abuse the platform to silence offensive researchers and the platforms don't care.

➡️ My recommendation remains ⬅️

  • contact vendors directly via email
  • use your national CERT for escalations

If you're in Europe: you're in luck, from 2027 the Cyber Resilience Act (CRA) will make it mandatory to have a responsible disclosure process, so European vendors have to answer to the national CERT (or get fined).

#PenerationTesting #pentesting #responsibledisclosure #infosec #cybersecurity #CRA #CyberResilienceAct

Transparency vs. Silence: If Advisories Don't Exist, Are Systems Really Secure?

What happens when security advisories aren't published? Lessons from PACS research: 20 CVEs, coordinated disclosure, patching, mitigation: transparency matters!

Tesla was among the systems successfully exploited at Pwn2Own Automotive 2026, where researchers demonstrated chained zero-day vulnerabilities against IVI systems and EV charging hardware.

All findings fall under coordinated disclosure, reinforcing the importance of independent testing, patch timelines, and supply-chain visibility as vehicles evolve into software-defined platforms.

Source: https://www.bleepingcomputer.com/news/security/tesla-hacked-37-zero-days-demoed-at-pwn2own-automotive-2026/

Measured discussion welcome. Follow TechNadu for neutral automotive security coverage.

#Tesla #AutomotiveInfosec #ZeroDay #Pwn2Own #EVSecurity #ResponsibleDisclosure

🇧🇩 Today I'm going to talk about Bondstein Technologies Limited, a company based in Dhaka, Bangladesh. One of their servers was found to be completely open and unprotected.

Bondstein Technologies Limited is a Dhaka-based technology company specializing in Internet of Things (IoT) solutions and frontier technologies. Founded in 2014, it has established itself as a leading player in Bangladesh for vehicle tracking, industrial automation, and smart connectivity.

What data was exposed?

On December 26, 2025, I discovered that the server was exposing a 22 GB SQL backup file. According to the file timestamps and metadata, this backup appears to have been publicly accessible since at least July 2025.Among the files in the backup was users.sql, which contained the following sensitive fields:

username, customer_name, First_name, Last_name, Phone_number, Additional_contact-number, email, password.

*I was able to confirm that some of the employee names were real.

Additional findings:

The exposed server's IP resolved to a properly certified HTTPS server using a subdomain under .bondstein.net. The same IP also hosted a login portal (which I did not attempt to access).With this information, we were able to accurately identify the owner and submit a responsible disclosure.

Notification:

All of this was detailed in the email I sent to several Bondstein employees on December 26, 2025. When I checked again on January 5, 2026, the exposure had been fully closed. I followed up via email to inquire about any possible reward. On January 6, they replied with the following message:

Hi Chum1ng0,

Thank you for your responsible and detailed disclosure regarding the open directory issue on our server. We sincerely appreciate you taking the time and effort to notify us of this vulnerability, which allowed us to address it quickly. Your commitment to ethical research is truly valued. We want to confirm that the issue has been fixed and access has been restricted. We would also like to clarify that the server you identified is a staging server kept for internal purposes, and not a production environment. Regarding your request for a reward, we currently do not have an official bug bounty program in place. However, we are grateful for your help in securing our infrastructure.

We appreciate your patience and look forward to potentially collaborating in the future should we establish a formal program.

Sincerely
Bondstein

-NOT REWARD-

#VDP #responsibleDisclosure #misconfigurations #Bangladesh #cybersecurity #bondstein

Responsible Disclosure: Chimoney Android App and KYCaid

https://shkspr.mobi/blog/2026/01/responsible-disclosure-chimoney-android-app-and-kycaid/

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization.

It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this, it uses the Ukranian KYCaid platform.

So far, so standard. But there's a small problem with how they both integrate.

I installed Chimoney's Android app and attempted to go through KYCaid's verification process. For some reason it hit me with this error message.

Well, I'd better click that email and report the problem.

Oh, that's odd. What happens if I click the protected link?

Huh! I guess I've been taken to Cloudflare's website. What happens if I click on the links on their page?

Looks like I can now visit any site on the web. If Cloudflare has a link to it, I can go there. For example, GitHub.

Why is this a problem?

MASTG-KNOW-0018: WebViews

One of the most important things to do when testing WebViews is to make sure that only trusted content can be loaded in it. Any newly loaded page could be potentially malicious, try to exploit any WebView bindings or try to phish the user. Unless you're developing a browser app, usually you'd like to restrict the pages being loaded to the domain of your app. A good practice is to prevent the user from even having the chance to input any URLs inside WebViews (which is the default on Android) nor navigate outside the trusted domains. Even when navigating on trusted domains there's still the risk that the user might encounter and click on other links to untrustworthy content

Emphasis added

A company's app is its sacred space. It shouldn't let anyone penetrate its inner sanctum because it has no control over what that 3rd party shows its customers.

There's nothing stopping an external service displaying a message like "To continue, please transfer 0.1 Bitcon to …"

(Of course, if your KYC provider - or their CDN - decides to turn evil then you probably have bigger problems!)

There are some other problems. It has long been known that people can use in-app browsers to circumvent restrictions. Some in-app browsers have insecure configurations which can be used for exploits. These sorts of "accidentally open" browsers are often considered to be a security vulnerability.

The Fix

Ideally, an Android app like this wouldn't use a web view. It should use a KYC provider's API rather than giving them wholesale control of the user experience.

But, suppose you do need a webview. What's the recommendation?

Boring old URl validation using Android's shouldOverrideUrlLoading() method.

Essentially, your app restricts what can be seen in the webview and rejects anything else.

Risk

Look, this is pretty low risk. A user would have to take several deliberate steps to find themselves in a place of danger.

Ultimately, it is "Code Smell" - part of the app is giving off a noxious whiff. That's something you cannot afford to have on a money transfer app. If this simple security fix wasn't implemented, what other horrors are lurking in the source code?

Contacting the company

There was no security.txt contact - nor anything on their website about reporting security bugs. I reached out to the CEO by email, but didn't hear back.

In desperation, I went on to Discord and asked in their support channel for help.

Unfortunately, that email address didn't exist.

I also tried contacting KYCaid, but they seemed unable or unwilling to help - and redirected me back to Chimoney.

As it has been over two month since I sent them video of this bug, I'm performing a responsible disclosure to make people aware of the problem.

#android #CyberSecurity #ResponsibleDisclosure #security #WebMonetization
Responsible Disclosure: Chimoney Android App and KYCaid

Chimoney is a new "multi-currency wallet" provider. Based out of Canada, it allows users to send money to and from a variety of currencies. It also supports the new Interledger protocol for WebMonetization. It is, as far as I can tell, unregulated by any financial institution. Nevertheless, it performs a "Know Your Customer" (KYC) check on all new account in order to prevent fraud. To do this,…

Terence Eden’s Blog