Setting the record straight on Cloud Access and Community

In recent days, media reports have circulated online regarding Bambu Lab’s actions toward a certain software modification. These reports have spread widely and sparked considerable discussion. We understand this and have no issue with it - it’s a healthy sign that the community is taking the matter seriously.

However, we would now like to clarify a few points that have been somewhat misinterpreted or unintentionally confusing.

First and foremost, this is not about OrcaSlicer or any other legitimate forks. This is not about prohibiting modification of the open source code. This is not about closing the code.

It is about the stability of our cloud infrastructure.

Bambu Lab has existed thanks to the community since day one. And we have always appreciated that, everywhere and at all times. Feedback, requests, and suggestions from users have helped us build better products.

This time, we had to act. Below, we explain why.

We fully understand that many users have their slicer of choice - tools developed by the community, full of features that sometimes even appeared there faster than in the official client. We respect that.

However, the modification referenced in recent reports did something entirely different from simply developing code.

Let us explain this very literally, because this is where the entire issue lies.

Bambu Studio is an open-source project under the AGPL-3.0 license. Anyone can take its code, modify it, and distribute it. This is not a matter of our “permission” - it is simply how the license and open source work.

That’s what OrcaSlicer does, and 734 other forks do as well. We have no issue with that and never have.

At the same time, a license for code is not a pass to our cloud infrastructure.

These are two completely different things, and the distinction between them is absolutely critical.

Our cloud is a private service. Access to it is governed by a user agreement, not the AGPL license.

And this is where the actual issue arises: the modification in question worked by injecting falsified identity metadata into network communication.

When this particular OrcaSlicer fork communicates with our cloud services, it quietly introduces itself as official Bambu Studio - with a hardcoded version number and all. Our servers see what looks like a legitimate client. They have no reason to question it. And that's precisely the point where code modification crosses into impersonation.

This is not only bypassing a technical limitation, but also impersonating another entity in communication with a server. And that is precisely the problem that requires us to respond.

It creates structural vulnerability. If this method were widely adopted or incorrectly configured, thousands of clients could simultaneously hit our servers while impersonating the official client. Our systems would have no way to distinguish traffic, because the requests would look identical.

We have documented incidents of service outages caused precisely by spikes in unauthorized traffic - overwhelming the servers, causing service disruptions affecting everyone. The cost was instability felt by all users.

Can this be completely eliminated? Honestly? No.

All companies operating in connected-device environments have been dealing with the same issue for decades. We can reduce risk, we can harden systems, but we cannot build a perfectly sealed wall.

That is why it is all the more important to respond to specific threats when they appear.

There is one more aspect of this situation we would like to address.

We run an active Bug Bounty Program - with rewards for critical discoveries. Findings reported through proper channels are not only rewarded, but also actually reach our teams and improve the product. We genuinely encourage the community to use it.

If you find a vulnerability, report it. That's the right channel, and it exists for a reason. Bambu Lab has a strong track record of working with white hat security researchers, and we continue to grow and improve the program.

The stability of the ecosystem is the foundation on which everything else depends

Without a properly functioning cloud, there is no remote monitoring, no one-click printing, no seamless integration with MakerWorld, the very features that define your Bambu experience.

We cannot sacrifice that stability for the sake of the smooth user experience we want to provide to our customers.

Therefore, we stand by our position. Modifying and distributing AGPL code - absolutely. But impersonating official clients in communication with our cloud infrastructure is not allowed.

We would also like to remind our advanced users who want more control over their devices, that Bambu Connect, LAN Mode and Developer Mode are available, if the cloud connection is not your first choice.

We invite collaboration, participation in the Bug Bounty Program and open dialogue. We also believe some boundaries are necessary to keep the platform reliable for everyone.