Do It by Code
54 subscribers
715 photos
100 videos
15 files
1.25K links
We uhhhhh... do things by coding them.
Download Telegram
CVE-2025-48827

Unauthenticated API Access in vBulletin:
vBulletin 5.0.0 through 5.7.5 and 6.0.0 through 6.0.3 allows unauthenticated users to invoke protected API controllers' methods when running on PHP 8.1 or later, as demonstrated by the /api.php?method=protectedMethod pattern, as exploited in the wild in May 2025.



- blog
- PoC (gist)
- PoC (by EgiX)
- kevintel
- CWE-424: Improper Protection of Alternate Path
- CWE-424 Example

#vulnerability #rce
🤓1
Recursive mutex misuse

Recursive mutex misuse occurs when a thread incorrectly attempts to acquire a recursive mutex multiple times from the same thread without first unlocking it, leading to a deadlock or unexpected behavior.


What is a Recursive Mutex?

• A recursive mutex (also known as a reentrant mutex) allows a thread to acquire the same mutex multiple times from the same thread without causing a deadlock.
• Each time the mutex is locked, an internal counter is incremented. The mutex is only released when the counter reaches zero, which happens when the thread unlocks the mutex the same number of times it locked it.


Potential Misuse Scenarios:

1. Incorrect Unlock Amount:
If a thread locks a recursive mutex multiple times but then unlocks it fewer times than it locked it, the mutex may become "permanently locked" in the sense that no other thread can acquire it.

2. Calling Unsafe Code:
If a thread accidentally calls unsafe code while holding a recursive mutex, and then attempts to lock it again, it could lead to unpredictable behavior.

3. Misunderstanding the Purpose:
Recursive mutexes are designed for situations where a thread needs to acquire the same mutex multiple times within the same execution context, such as when a function calls itself or when multiple parts of an object need to be protected by the same lock. Misusing them for situations where they're not necessary can lead to performance overhead and make the code harder to understand.
Do It by Code
2. Calling Unsafe Code:
Unsafe Code: "Unsafe" code typically refers to:
1. Code that can bypass the language's safety guarantees
2. Code that might interact directly with hardware or memory
3. Code that could cause undefined behavior

The Problem Scenario:

1. Thread acquires a recursive mutex (locks it)
2. While holding this lock, it calls some "unsafe" code
3. This unsafe code tries to lock the same mutex again
4. Something goes wrong because the unsafe code doesn't follow proper rules

Example in C++:


#include <mutex>
#include <iostream>

std::recursive_mutex rmutex;

void unsafe_function() {
// This function doesn't properly handle the mutex
// Maybe it was written by another team or uses a C library

// It tries to lock the mutex but doesn't unlock it properly
rmutex.lock();

// Maybe it throws an exception or returns early
throw std::runtime_error("Something went wrong!");

// The unlock never happens!
rmutex.unlock();
}

void normal_function() {
// Lock the recursive mutex
rmutex.lock();

std::cout << "Doing some work with the lock held" << std::endl;

try {
// Call the unsafe function while holding the lock
unsafe_function();
} catch (const std::exception& e) {
std::cout << "Caught exception: " << e.what() << std::endl;
}

// We think we only need to unlock once, but the unsafe function
// has left the mutex in an inconsistent state
rmutex.unlock();
}


The real danger is that unsafe code might:
- Not follow proper locking/unlocking patterns
- Manipulate the mutex's internal state directly
- Cause memory corruption that affects the mutex
- Create deadlocks or resource leaks

This is why languages with memory safety like Rust mark such operations as unsafe - they're telling you "be extremely careful here, the compiler can't protect you."
Do It by Code
Recursive mutex misuse Recursive mutex misuse occurs when a thread incorrectly attempts to acquire a recursive mutex multiple times from the same thread without first unlocking it, leading to a deadlock or unexpected behavior. What is a Recursive Mutex?…
before using a Mutex in a programming language, always make sure whether that specific mutex implementation is a recursive mutex (reentrant mutex) or a normal mutex.

Some languages such as C++ have different implementations with clear names:
- std::mutex
- std::recursive_mutex
- std::recursive_timed_mutex
etc...

but some languages such as GDScript's Mutex class only have a single Mutex class and it's a reentrant mutex.

And some other languages such as Golang, do not recommend using a recursive mutex at all.
Do It by Code
And some other languages such as Golang, do not recommend using a recursive mutex at all.
Why doesn't don't Go developers recommend using a recursive mutex?

Russ Cox from the Go development team:
(SO link, Google group Link)

Tl;dr: They make the project so complex and home to bugs, that their benefits is much much less than their damage.
One thing that people make mistake is: most of the times we assume only calling .lock method on a mutex can cause a deadlock, however .unlock is also very important...

You need to ensure you only call unlock after the mutex has been locked by the current thread, otherwise you may get deadlock, crashes or undefined behavior. (do you notice the "may"? because it entirely depends on the implementation of the mutex, or the platform)

For example, in C++:
- mutex.unlock
- timed_mutex.unlock
- recursive_mutex.unlock
- recursive_timed_mutex.unlock
- shared_mutex.unlock
- shared_timed_mutex.unlock

All of the articles above are saying the same thing:
"The mutex must be locked by the current thread of execution, otherwise, the behavior is undefined."

In other programming languages, such as Golang, you will panic (or exception).
Do It by Code
One thing that people make mistake is: most of the times we assume only calling .lock method on a mutex can cause a deadlock, however .unlock is also very important... You need to ensure you only call unlock after the mutex has been locked by the current…
In GDScript? you might get nothing.
no errors, no warnings, no logs, no nothing. since it's built on top of C++.

However, sometimes you might get deadlocks.
if the deadlock happens on your main thread, the whole code editor will freeze.
If you are running an exported game, the game will freeze, no logs.
If you look at event viewer, you will encounter this error:

The program name.exe version 1.0.0.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Security and Maintenance control panel.


not helpful at all. You will have to put breakpoints yourself and debug the code (painful).

Next thing is that, this might not be reproducible in 100% of cases. for example in my case, it was only happening on macos and windows, the linux version was working fine. Even more confusing and weird.
Do It by Code
In GDScript? you might get nothing. no errors, no warnings, no logs, no nothing. since it's built on top of C++. However, sometimes you might get deadlocks. if the deadlock happens on your main thread, the whole code editor will freeze. If you are running…
oh btw if this happens in a background thread...then may God help you 🙏

because as far as I know, Godot's debugger does not fully support debugging background threads yet (idk maybe this is implemented in recent versions of 4.*)

But yes, even if it supports, it will just make you more confused, because even if the editor does not freeze, but things just might not be working the way they are supposed to work...
welcome to concurrency hell (if you don't manage it correctly that is)
This media is not supported in your browser
VIEW IN TELEGRAM
A footage of code editor freezing when a deadlock happens due to incorrect call to mutex.unlock...
if I uncomment those lines (which will no longer call unlock method), everything will work fine.

This is because of incorrect call to mutex.unlock method.
related GitHub issue
Please open Telegram to view this post
VIEW IN TELEGRAM
evil-winrm-py

evil-winrm-py is a python-based tool for executing commands on remote Windows machines using the WinRM (Windows Remote Management) protocol. It provides an interactive shell with enhanced features like file upload/download, command history, and colorized output. It supports various authentication methods including NTLM, Pass-the-Hash, Certificate, and Kerberos.
An attempt to answer the age old interview question "What happens when you type google.com into your browser and press enter?"

https://github.com/alex/what-happens-when
2
What is Microsoft doing
Prompt:
a young woman drawing a simple stickman figure in paper with her pencil, from an empty paper to a stickman figure with each pencil stroke


Model: Google Veo 3
#veo3