David Oduse

On June 28, 2026, I discovered that our Monesize demo environment was running nginx 1.24.0, a version vulnerable to multiple critical security flaws including CVE-2026-42945, a remote code execution vulnerability with a CVSS score of 9.2. This post documents exactly how I identified the problem, patched it, and verified the fix, including a misconfiguration that took our applications offline for a few minutes in the process. The Discovery I was testing our authentication flow using Burp Suite Community Edition when I noticed something in the response headers coming back from our API gateway: HTTP/1.1 403 Forbidden Server: nginx/1.24.0 (Ubuntu) The Server header was leaking the exact nginx version and operating system. This is not just a cosmetic issue. Version disclosure is a reconnaissance gift. It gives an attacker a precise target to query against known vulnerability databases. Instead of probing blindly, they know exactly what they are dealing with and can search for working e...

This writeup documents my exploitation of a vulnerable Windows machine using Metasploit. The goal was to identify the exposed attack surface, discover a critical vulnerability, exploit it, obtain privileged access, retrieve the flag file, and extract the NTLM hash of a user account. The exercise covered the full penetration testing workflow: Reconnaissance Vulnerability identification Exploitation Privilege verification Post-exploitation activities Reconnaissance The first step in any penetration test is understanding what is exposed. You cannot attack what you cannot see, and you should not attack blindly what you can. I ran an Nmap version scan against the target: nmap -sV <target-ip> The scan revealed the following open ports and services: 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 3389/tcp open tcpwrapped 49152/tcp open msrpc 49153/tcp open msrpc 49154/tcp open msrpc 49155/tcp open msrpc The critical discovery was: 445/tcp ope...

As Monesize Core evolved into a modular business platform, more parts of the system started depending on events. Accounting needed to react to sales. Inventory needed to react to purchases. Activity logs needed to capture important actions. Notifications needed to respond to business events. The architecture naturally moved toward an event-driven approach. A service performs a business operation, emits an event, and other modules react. At first glance, this looks simple. A transaction happens. An event is emitted. Listeners process the event. The problem is that distributed systems are not defined by what happens when everything works. They are defined by what happens when something fails. The question I eventually had to answer was: how do I guarantee that a business event is never silently lost? The Gap Between Database Writes and Events The first version of event handling looked simple: await prisma.sale.create({ data: saleData }); eventBus.emit('sale:created', {...

One of the most common patterns in software engineering is solving reliability problems by introducing more infrastructure. Need background jobs? Add Redis. Need reliable event delivery? Add Kafka. Need asynchronous processing? Add a queue. Need distributed messaging? Add another service. Sometimes that is the right decision. Sometimes it is not. Recently, I implemented the Event Outbox pattern across Monesize Core to guarantee reliable cross-module event delivery. The obvious question is: why not just use Redis, Kafka, RabbitMQ, or BullMQ? The answer comes down to architecture. Monesize Core is not a typical multi-tenant SaaS platform. Every customer receives their own isolated deployment. Their own application environment. Their own database. Their own infrastructure footprint. This architectural decision has implications. Every new infrastructure dependency added to the platform becomes a dependency that must exist in every customer deployment.  Introducing Redis w...

When people think about product management, they often think about the formal role. A person managing a roadmap. Writing product requirements. Prioritizing features. Working with engineering and design teams. Those are all parts of product management, but they are not the foundation. The foundation is understanding why something should exist. Before a company has a product team, someone has to answer the hardest product questions. What problem are we solving? Who has this problem badly enough to care? Why does this problem matter now? What should we build? What should we deliberately not build? How do we know we are creating value? In many early-stage companies, the founder is the first product manager. Not because they have the title. Because they are forced to do the work. When there is no existing market, no established roadmap, and no previous data to rely on, someone has to create the initial product thesis. That is product management at its deepest level. A founder does not start...

 A lot of product discussions focus on what to build. Roadmaps. Features. User stories. Prioritization frameworks. Backlogs. But one of the most important product skills is rarely discussed: knowing what not to build. Building software is expensive. Every feature has a cost beyond the initial engineering work. It adds complexity. It creates maintenance requirements. It increases support burden. It introduces more things that can fail. It affects the experience of every future user. A feature is not just a line of code. It is a long-term commitment. This is why product decisions cannot be made by simply asking "Can we build this?" The better question is "Should this exist?" Those are completely different questions. A lot of teams confuse customer-driven product development with building everything customers request. A customer asks for something. The team adds it to the roadmap. Over time, the product becomes a collection of individual requests rather tha...

 Getting customers to try a product is not the same as building something valuable. A lot of products can attract attention. A launch can create excitement. A sales process can convince someone to sign up. A founder's reputation can create initial interest. But the real test starts after the excitement disappears. Do customers continue using the product? Do they depend on it? Would removing the product create a real problem for them? That is where retention becomes important. Product validation is a progression. An idea is a hypothesis. You believe a problem exists. You believe a specific group of people experiences that problem. You believe your solution creates enough value that they will pay for it. At this stage, nothing is proven. It is only an assumption. The first paying customer is evidence. It proves that someone sees enough value to exchange money. But one customer paying once does not mean you have built something valuable. They may have been curious. They ma...

 One of the hardest parts of building products is learning that customers are not always asking for features. They are usually describing problems. The mistake many product teams make is taking every request literally. A customer says "We need a feature that allows us to do X." The immediate reaction becomes "Let's build X." But the better question is "Why do you need X?" The requested solution is not always the actual problem. A customer may ask for a feature because they are currently working around a broken process. They may have created a manual workaround because the underlying system does not support their workflow. Building the workaround into the product does not always solve the deeper problem. Sometimes it just creates more complexity. I experienced this while thinking about product requests for Monesize Core. A small business owner suggested a feature that would allow her to create editable price lists and send different versions...

There is a difference between building software and building systems. A lot of software can be built quickly today. The barrier to creating an interface, connecting APIs, and producing a functional application has reduced significantly. But businesses do not run on interfaces. They run on systems. A system is more than the software users see. It includes the workflows, rules, permissions, data structures, operational processes, security controls, and the decisions that happen around the software. This distinction matters because many products look impressive from the outside but lack the foundation required for serious business operations. A dashboard can be copied. A workflow embedded into a company's daily operations is much harder to replace. When I think about enterprise software, I do not think only about features. A feature might be: "Allow a user to submit a VAT return." A system question is different. Who is allowed to submit it? What audit trail exist...