#responsibledisclosure — Public Fediverse posts

@wdormann Of course Microsoft used their GitHub ownership to remove the repo instead of fixing both problems (the exploit and the video requirement).

#bluehammer #github #censorship #responsibledisclosure

Companies will put up all kinds obstacles to responsible disclosure for researchers to get around to make their own lives easier. But they often forget that in the end it is researcher who calls the shots. It is the researchers vuln and they can do whatever they want with it.

https://www.bleepingcomputer.com/news/security/disgruntled-researcher-leaks-bluehammer-windows-zero-day-exploit/#comments

#vulnerability #disclosure #responsibledisclosure #windows #microsoft

RE: https://mastodon.nl/@SIDN/116317873852576082

Security.txt is een relatief nieuwe standaard, die beveiligingsonderzoekers helpt om kwetsbaarheden te melden. Dit draagt bij aan een veiliger internet.

@SIDN heeft haar informatiepagina over deze standaard bijgewerkt: https://www.sidn.nl/moderne-internetstandaarden/security-txt Binnenkort verschijnt ook een Engelse vertaling.

Wil je weten of security.txt op jouw website correct is ingesteld? Test het op https://Internet.nl!

#securitytxt #internetstandards #security #responsibledisclosure

How not to do #ResponsibleDisclosure in a nut shell:

https://github.com/rustdesk/rustdesk/issues/14576

#RustDesk #security

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

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

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

🇧🇩 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

🆕 blog! “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.

But it has a security flaw which cannot be ignored.

👀 Read more: https://shkspr.mobi/blog/2026/01/responsible-disclosure-chimoney-android-app-and-kycaid/
⸻
#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, 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.

🐱 New Blog Post: Petlibro Smart Pet Feeder Vulnerabilities (Partially Fixed, $500)

Found critical vulns in Petlibro - one of the biggest smart pet feeder companies:

• Auth bypass via broken OAuth - just need Google ID (public info via Google APIs) to login as anyone
• Access any pet's data, devices, serial numbers, MAC addresses
• Hijack any device - change feeding schedules, access cameras
• Access private audio recordings (mealtime messages to pets)
• Add yourself as shared owner to any device

The worst part? They "fixed" the auth bypass by making a new endpoint... but left the old vulnerable one active for "legacy compatibility." Two months later, still working.

Also tried to get me to sign an NDA AFTER paying the bounty. That's not how contracts work.

Full writeup: https://bobdahacker.com/blog/petlibro

#InfoSec #BugBounty #ResponsibleDisclosure #IoT #Petlibro #Security #Privacy #CyberSecurity #SmartHome #OAuth

🎵 New Blog Post: Bandsintown Verification Bypass (Fixed, $200 + Swag)

Found a way to claim any unclaimed artist page on Bandsintown without verification:

• Discovered API endpoint from requesting to join Bieber's team
• Used same endpoint on Rick Astley (unclaimed) - bypassed all OAuth/social verification
• Got full access to 191k followers, their emails, names, locations
• Could send push notifications and post as any unclaimed artist (including diddy xd)

I could have rickrolled 191k people for real. I did not.

Bandsintown handled it well - fast fix, honest about bounty limitations, shipped me swag.

Also found a new bypass while writing this - currently disclosing responsibly.

Full writeup: https://bobdahacker.com/blog/bandsintown

#InfoSec #BugBounty #ResponsibleDisclosure #Bandsintown #Security #Privacy #CyberSecurity #RickAstley #APISecuity #Music

🔓 Found critical vulns in Taimi (LGBTQ+ dating app) - all fixed, $10k bounty

What I found:

• "Expiring" videos didn't expire, URLs stayed valid forever
• Decrement attachment ID = anyone's private videos
• Location feature bypassed photo permission checks (why upload a map preview image through the photo system??)
• Fake system messages (made a Raid Shadow Legends sponsorship lol)

The good news: Taimi actually handled this right. Fast response, $10k bounty, everything fixed quickly. No lawyers, no threats.

This is how disclosure should work. Take notes, Lovense.

Full writeup: https://bobdahacker.com/blog/taimi-idor

#InfoSec #BugBounty #ResponsibleDisclosure #IDOR #Taimi #DatingApp #Security #Privacy #CyberSecurity #LGBTQ

🆕 blog! “Responsible Disclosure: Joiners, Movers, and Leavers in NHS BSA”

Many many years ago, I did some work for the NHS. As part of that, I was given access to certain GitHub organisations so that I could contribute to various projects. Once I left that job my access was revoked.

Mostly.

A few weeks ago, I received…

👀 Read more: https://shkspr.mobi/blog/2025/12/responsible-disclosure-joiners-movers-and-leavers-in-nhs-bsa/
⸻
#CyberSecurity #github #nhs #ResponsibleDisclosure

Responsible Disclosure: Joiners, Movers, and Leavers in NHS BSA

https://shkspr.mobi/blog/2025/12/responsible-disclosure-joiners-movers-and-leavers-in-nhs-bsa/

Many many years ago, I did some work for the NHS. As part of that, I was given access to certain GitHub organisations so that I could contribute to various projects. Once I left that job my access was revoked.

Mostly.

A few weeks ago, I received this email from GitHub.

On the surface, this is a sensible email. They want all their members to only have strong 2FA and I still had SMS configured as a fallback method. Except, of course, I should not be a member. I should have been kicked out when I handed back my laptop and lanyard. There was still a bit of pandemic pandemonium about - but surely in the last few years someone should have audited the organisation's membership?

The JML process is critical to cybersecurity. There's no point having fancy controls if you don't revoke the permissions of people who are no longer entitled to access. On a fully integrated system this is (usually) easy - untick a box on Active Directory or whatever and *poof* the user is banned.

But with external systems the problem is harder. You now need to keep track of external usernames, synchronise them with internal names, periodically check them for updates, integrate with an API, and - in some cases - take manual action. It's clear that this particular bit of the NHS had slipped up. Looking through the private list of collaborators, there were many old accounts.

I was able to see all private collaborators:

I could see all private repositories:

I even had access to create new repositories - including special ones:

To be abundantly clear, there was no medical data on GitHub. There was no patient data available for me to view. Absolutely nothing medically sensitive was stored there. This isn't a GDPR or medical privacy issue. If I had made any changes to the code stored on there, it would never have made it to production. There were no API keys or sensitive data or passwords for me to exfiltrate. The NHS BSA is a business unit - not a medical unit.

Nevertheless, it is important that all parts of a large organisation are able to quickly and competently remove users once they have left.

Timeline

• 2025-10-17
  • Received GitHub email.
  • Visited https://www.nhs.uk/.well-known/security.txt to get details of how to raise security issues.
  • Raised the issue on HackerOne
• 2025-10-21
  • After triage, the issue was assigned directly to the BSA.
• 2025-10-31
  • I was removed from the organisation.
  • Requested permission to publish this post. No objection received.
• 2025-12-02
  • Published

#cybersecurity #github #nhs #responsibleDisclosure

#sicherheit geht uns alle an:
Welche Punkte/Regelungen/Belohnungen erwartet ihr in der #responsibledisclosure Policy von einer Seite wie LinuxNews.de? Bin da aktuell etwas planlos…

Hashtags damit wir volle Kanne in der #itsecurity Bubble einschlagen: #cybersecurity #cybersec #opsec #security #databreach #hackerangriff #hacker #itsec #credentialtheft #digitalsafety #digitalesicherheit #threatintelligence

@ProPublica

Sounds like #ResponsibleDisclosure

(post describes my experience and does not represent my employer)

LinkedIn post (see also screenshot): https://www.linkedin.com/posts/johannes-greil-189bb813b_cybersecurity-infosec-workexaminer-activity-7386384177107116032-T3ow

I was involved in the mentioned cases and can only warn every penetration tester of bug bounty platforms.

I worked in an official CVE Numbering Authority (CNA) and we were legally threatened multiple times by vendors.

While bug bounty platforms claim to be a "safe harbor" and claim to mediate in difficult situations, in every instance they told us we have to adhere to the policies of the platform and didn't help any further. So, any user of these platforms has a double liability: first, to your country's law, second to the bug bounty platform's policy.

In the case of #HackerOne, they delegate this policy to the vendors:
"Security Teams will publish a program policy [...]. You should always carefully review this program policy prior to submission as they will supersede these [H1's] guidelines in the event of a conflict."
Source: https://www.hackerone.com/terms/disclosure-guidelines

So vendors can create a policy "no one is allowed to publish if we don't agree" and defeat responsible disclosure. In fact, some vendors do exactly that. Bug bounty platforms are paid by vendors and have no incentive to protect the researchers.

➡️ If you submit your vulnerability via email or similar directly to the vendor, then you are not legally bound to the bug bounty program's policy.
➡️ If there is trouble, involve your national CERT, they truly mediate.

Stay safe and warn your pentesting friends.

#PenetrationTesting #CVE #ResponsibleDisclosure

#Bundesverfassungsgericht @BGH_Bund lehnt Beschwerde im Fall #ModernSolution ab | heise online https://www.heise.de/news/Bundesverfassungsgericht-lehnt-Beschwerde-im-Fall-Modern-Solution-ab-10663649.html #Hacking #Hackerparagraf #Datenschutz #privacy #StGB202a #Verfassungsbeschwerde #ResponsibleDisclosure #Deutschland

🤖 Hacked China's Biggest Robotics Company (Pudu Robotics)

Pudu makes those cat-faced BellaBot robot waiters you see in restaurants, plus cleaning robots, disinfection bots, and even FlashBots with mechanical arms for offices.

Found critical vulnerabilities in their app controlling their entire global fleet:

• Zero authentication on APIs
• Could control any robot worldwide
• Accept 20k store IDs in single request, no rate limiting
• Could steal food, documents, redirect hospital medicine delivery
• FlashBot with arms could grab files & use elevators

Reported Aug 12. Sent emails to sales, support, tech teams - all ignored.

Had to email Skylark Holdings (7000+ restaurants) and Zensho directly about their compromised robots.

Pudu responded in 48hrs with obvious ChatGPT template - forgot to replace "[Your Email Address]" placeholder. Fixed 2 days later.

Thousands of robots (BellaBots, KettyBots, FlashBots, etc) in hospitals, restaurants, offices worldwide were vulnerable for a long time.

Full Technical Writeup: https://bobdahacker.com/blog/hacked-biggest-chinese-robot-company

#infosec #robotics #BellaBot #PuduRobotics #security #vulnerability #responsibleDisclosure #cybersecurity

🆕 blog! “Security Flaws in the WebMonetization Site”

I've written before about the nascent WebMonetization Standard. It is a proposal which allows websites to ask users for passive payments when they visit. A visitor to this site could, if this standard is widely adopted, opt to send me cash for my very fine blog…

👀 Read more: https://shkspr.mobi/blog/2025/08/security-flaws-in-the-webmonetization-site/
⸻
#BugBounty #CyberSecurity #ResponsibleDisclosure #WebMonetization #xss

Security Flaws in the WebMonetization Site

https://shkspr.mobi/blog/2025/08/security-flaws-in-the-webmonetization-site/

I've written before about the nascent WebMonetization Standard. It is a proposal which allows websites to ask users for passive payments when they visit. A visitor to this site could, if this standard is widely adopted, opt to send me cash for my very fine blog posts.

All I need to do is add something like this into my site's source code:

<link rel="monetization" href="https://wallet.example.com/edent">

A user who has a WebMonetization plugin can then easily pay me for my content.

But not every website is created by an individual or a single entity. Hence, the creation of the "Probabilistic Revenue Share Generator".

Probabilistic revenue sharing is a way to share a portion of a web monetized page's earnings between multiple wallet addresses. Each time a web monetized user visits the page, a recipient will be chosen at random. Payments will go to the chosen recipient until the page is closed or reloaded.

Nifty! But how does it work?

Let's say a website is created by Alice and Bob. Alice does most of the work and is to receive 70% of the revenue. Bob is to get the remaining 30%. Within the web page's head, the following meta element is inserted:

<link   rel="monetization"   href="https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDcwLCJBbGljZSJdLFsiaHR0cHM6Ly93aGF0ZXZlci50ZXN0LyIsMzAsIkJvYiJdXQ"/>

The visitor's WebMonetization plugin will visit that URl and be redirected to Alice's site 70% of time and Bob's 30%.

If we Base64 decode that weird looking URl, we get:

[   [      "https://example.com/",       70,      "Alice"   ],   [      "https://whatever.test/",       30,      "Bob"   ]]

Rather than adding multiple URls in the head, the site points to one resource and lets that pick who receives the funds.

There are two small problems with this.

The first is that you have to trust the WebMonetization.org website. If it gets hijacked or goes rogue then all your visitors will be paying someone else. But let's assume they're secure and trustworthy. There's a slightly more insidious threat.

Effectively, this allows an untrusted 3rd party to use the WebMonetization.org domain as an open redirect. That's useful for phishing and other abuses.

For example, an attacker could send messages encouraging people to visit:

https://webmonetization.org/api/revshare/pay/W1siaHR0cHM6Ly9leGFtcGxlLmNvbS8iLDk5LCJpbWciXV0

Click that and you'll instantly be redirected to a domain under the attacker's control. This could be particularly bad if the domain encouraged users to share passwords or other sensitive information.

If the Base64 data cannot be decoded to valid JSON, the API will echo back any Base64 encoded text sent to it. This means an attacker could use it to send obfuscated messages. Consider, tor example:

https://webmonetization.org/api/revshare/pay/W1siUGxlYXNlIHZpc2l0IFJlYWxfZ29vZF9DYXNpbm9zLmJpeiBmb3IgbG90cyBvZiBDcnlwdG8gZnVuISEhIiwxMjM0NTYsImltZyJdXQ==

Visit that and you'll see a message. With a bit of effort, it could be crafted to say something to encourage a visitor to enter their credentials elsewhere.

When I originally reported this, the site could be used to to smuggle binary payloads. For example, this URl would display an image - however, it seems to have been fixed.

Nevertheless, it is important to recognise that the WebMonetization.org domain contains an unvalidated redirect and forwarding vulnerability.

I recommended that they ensured that the only URls which contain legitimate payment pointers should be returned. I also suggested setting a maximum limit for URl size.

Timeline

• 2025-03-27 - Discovered and disclosed.
• 2025-08-05 - Remembered I'd submitted it and sent a follow up.
• 2025-08-26 - Automatically published.
• 2025-08-27 - A day after this post was published, the issue was made public on their repo.
• 2025-09-10 - Confirmed fixed.

#BugBounty #CyberSecurity #ResponsibleDisclosure #WebMonetization #xss

Back in February I discovered two vulnerabilities in the TMO-100 TETRA data modem from Piciorgros, a Cologne-based manufacturer. Their reaction during carnival season was stellar. Then it took five months for the #KRITIS operator we worked with to install the updates.

Unauthorized log
data access: https://rt-solutions.de/piciorgros/Piciorgros_TMO-100_IP-Logger_en.pdf

Unauthorized
configuration change via TFTP
(CVE-2025-29617): https://rt-solutions.de/piciorgros/Piciorgros_TMO-100_TFTP_en.pdf

CC @HonkHase

#TETRA #InfoSec #ResponsibleDisclosure

In August 2020, @SchizoDuckie and I published what was to become the first of a series of articles or posts called "No Need to Hack When It's Leaking."

In today's installment, I bring you "No Need to Hack When It's Leaking: Brandt Kettwick Defense Edition." It chronicles efforts by @JayeLTee, @masek, and I to alert a Minnesota law firm to lock down their exposed files, some of which were quite sensitive.

Read the post and see how even the state's Bureau of Criminal Apprehension had trouble getting this law firm to respond appropriately.

https://databreaches.net/2025/07/04/no-need-to-hack-when-its-leaking-brandt-kettwick-defense-edition/

Great thanks to the Minnesota Bureau of Criminal Apprehension for their help on this one, and to @TonyYarusso and @bkoehn for their efforts.

#dataleak #misconfiguration #incidentresponse #incidentmanagement #responsibledisclosure #securityalert #infosec

A state forensics lab was leaking its files. Getting it locked down involved a number of people, notably @JayeLTee and @masek , although yours truly was also involved, as were others:

https://databreaches.net/2025/06/22/a-state-forensics-lab-was-leaking-its-files-getting-it-locked-down-involved-a-number-of-people/

#dataleak #responsibledisclosure #infosec #govsec

Related:
https://jltee.substack.com/p/forensic-lab-with-links-to-montana-doj-leaks-phone-extracts

https://blog.literarily-starved.com/2025/06/postmortem-assumed-doj-montana-leak-of-phone-dumps/

Great thanks to @adamshostack for getting people together to think about this issue and to make recommendations to #HHS under the #HIPAA Security Rule.

https://shostack.org/blog/security-researcher-comment-on-hipaa-security-rules/

Direct link to comments to HHS by @adamshostack, @dykstra, Fred Jennings, Chloé Messdaghi, and me:

https://downloads.regulations.gov/HHS-OCR-2024-0020-4673/attachment_1.pdf

#GoodFaith #SecurityRule #ResponsibleDisclosure #VDP

@cccpresser Der in Deutschland politisch gewollte #ResponsibleDisclosure Prozess ist offensichtlich:
1) 4chan.
2) There’s no step 2.

(Hat #ModernSolution eigentlich Kunden und ab wann ist es fahrlässig, einer Firma mit dieser Expertise (Datenbank-Passwort für alle Kunden im Executable) PII anzuvertrauen?)

Xiaomi and WPS Vulnerabilities: File Overwrite Risks Alert – Source: securityboulevard.com https://ciso2ciso.com/xiaomi-and-wps-vulnerabilities-file-overwrite-risks-alert-source-securityboulevard-com/ #microsoftthreatintelligence #rssfeedpostgeneratorecho #SecurityBloggersNetwork #responsibledisclosure #CyberSecurityNews #CybersecurityNews #SecurityBoulevard #GooglePlayStore #Patchmanagement #vulnerabilities #MobileSecurity #Android

Scheint so, als ob auch #koelnMesse ein opt-out aus #responsibleDisclosure durchgeführt habe. Ab wann gilt eigentlich für alle Firmen in #Neuland ein #optIn? Es ist doch mittlerweile sehr offensichtlich, dass es in Deutschland wesentlich stressärmer ist, Fuck-Ups von Firmen irgendwo zu verkaufen oder einfach so anonym zu veröffentlichen, als diese der Firma mitzuteilen.

https://www.golem.de/news/moegliche-schwachstelle-entdeckt-ploetzlich-zeuge-2405-184871.html

Koelnmesse GmbH hält anscheinend nicht so viel vom Responsible-Disclosure-Verfahren, sondern verklagt lieber nette Menschen, die helfen wollen.

https://unverantwortli.ch

#Koelnmesse #ResponsibleDisclosure #Chemnitz #Köln #apex_1337 #apex1337

** UPDATE **

I've taken this down for now. I'm looking into whether I need to do responsible disclosure. If you're an expert in this area, please reach out. Thanks!

#responsibleDisclosure

** Original post **

I published part 7 of my bike blog. This one is pretty cool, in my opinion. I discover that the access controls that ASI implemented in their electronic speed controls are easily bypassed with a brute-force attack. I also philosophize a bit about the implications of that.

https://housedillon.com/blog/flash-part-seven/

#bruteForceAttack #crack #reverseEngineer #rust #ebike #ebikes

The advisory of the authenticated command injection I found on Cacti 1.2.24 has been published (CVE-2023-39362).

https://github.com/Cacti/cacti/security/advisories/GHSA-g6ff-58cj-x3cp

#security #cybersecurity #websecurity #appsec #applicationsecurity #hacking #responsibledisclosure #exploit #cacti #rce #commandinjection #remotecommandexecution #cve202339362

#cdu #cduconnect #rezo #söder #wittmann #lilithwittmann #csu #kanzlerkandidat #youtube #youtuber #zerstörungdercdu #laschet #hacker #hacking #sicherheitslücke #whitehat #responsibledisclosure #it #itsicherheit #strafanzeige #anzeige #union #digitalisierung #neuland #datenschutz #dsgvo #privatsphäre #wahlkampf #bundestagswahl #btw21 #app #cduapp #jäger #jagen #ccc #shootthemessenger #whistleblower #demokratie #politik #internet #technologie #karikatur #cartoon

© https://pfohlmann.de/

#cdu #cduconnect #rezo #söder #wittmann #lilithwittmann #csu #kanzlerkandidat #youtube #youtuber #zerstörungdercdu #laschet #hacker #hacking #sicherheitslücke #whitehat #responsibledisclosure #it #itsicherheit #strafanzeige #anzeige #union #digitalisierung #neuland #datenschutz #dsgvo #privatsphäre #wahlkampf #bundestagswahl #btw21 #app #cduapp #jäger #jagen #ccc #shootthemessenger #whistleblower #demokratie #politik #internet #technologie #karikatur #cartoon

© https://pfohlmann.de/