Veeam 12 still Security Fixes?

[HansMeiser]

Hello,

since September 2025 Veeam 12 is in "End of Fix" State. So we cant expect new updates etc., which is fine. But can we expect further security patches that would be necessary in case of a problem?
I wonder if V12 was really not affected by CVE-2025-55125 and CVE-2025-59469 or only V13 was fixed. According to my colleague, no more security patches will be released for v12.
Strictly speaking version 12.3.2.4165 was released on 14. Oct. 2025, so this was already after "End-Of-Fix".
Please help me to understand this situation and classify the dates.

Thanks,
Hans

[david.domask]

Hi Hans,

>I wonder if V12 was really not affected by CVE-2025-55125 and CVE-2025-59469 or only V13 was fixed

As noted in our KB article, only v13 is affected by these items.

Veeam's Product Life Cycle is defined by main version, and it's best to upgrade to the current version as soon as time allows. Our focus is always on version that have not reached End of Fix. Is there a blocker that prevents you from upgrading to v13?

[HansMeiser]

Hello,

we build a new backupsystem in may/jun 2026, preparation are running. The new system will have v13 from the beginning. In my opinion it is only needed to update the current system to v13 if v12 is excluded from security fixes by now.
my mate says end-of-fix also means end-of-security-fixes. if this is true we should upgrade to v13 asap.

Thanks,
Hans

[HansMeiser]

Hello,

no other explicit answers to this topic?
This should be an eminent question to all v12 Users.
It is still unanswered: Will v12 get at least security-fixes? Linked Product LifeCycle says no.

Thanks,
Hans

[david.domask]

Hi Hans,

As noted, our focus is always on the newest releases. Products still under support may receive additional patches / fixes on a case by case basis, however it is generally best to upgrade sooner than later.

[kevin.boddy]

Hi,

We get told V12 fixes will be on case by case basis and to get upgraded to the current version as soon as time allows but when I bring up the fact that V13 has been a disaster for us with so many problems still not fixed, I am told why didn't you wait and stay on v12.

Which is it? Install broken V13 software or stay on working V12 but risk not getting any security fixes?

Thanks
Kevin

[ITP-Stan]

We are still on V12 as well.
I tried V13 in my homelab personally and was disappointed by the load it generates.
It's become such a bloated piece of software, the system requirements are ludicrous.
And all the unused plugins & services are installed by default & running to use even more resources.

[david.domask]

Kevin, Stan,

I appreciate your points and am sorry to hear you had challenges on v13; for those items please do create cases and let Veeam Support review, and for feature requests / requests for change please create new topics so we can review the situation and keep this topic focused on the question from the topic creator.

Updating to the latest supported version is always our recommendation.

[kevin.boddy]

So basically.
No guaranteed fixes available for V12.
Install buggy V13 instead.

[JPMS]

Veeam really need to get a grip on this sort of stuff. They seem to have lost all interest in what their customers need and what modern IT standards require.

There is already a significant discussion on the massive bloatware that Veeam is becoming here post541369.html. I only mention this because it is another example of how Veeam has lost touch with what IT professionals need.

Backup software is one of the critical parts of IT infrastructure. It is not something you rush to change when a vendor brings out a major new version with lots of changes. Does Veeam not understand that? Are your own internal IT practices so poor that you leap on every bit of shiny new stuff that's dangled in front of you as soon as it comes out?

You even make yourself look foolish - https://www.veeam.com/product-lifecycle.html. End of Fix for v12, September 2025, Release Date v13, November 2026! You're on your own for the gap between?!

I get that you want to move people on ASAP but it is rarely that simple for us. I can just about live with a 'no fixes' policy but it is essential that there is a guarantee of security fixes for a reasonable period of time. I would suggest six months, so upgrades can be properly planned, tested and implemented.

[HolgerE]

Major version upgrades were no big deal the last 10 years.
But after upgrading our (quite small) environment from v12 to v13 shows one bug after another. We have the second private fix running, now we are able to backup VMs without abortions again (this fix is still not public). But we still have a lot of warnings.
So I also don't understand why Veeam pushes people to upgrade to an unstable v13.
Currently we (have to) advise all our customers to stay at v12.

[HannesK]

Hello,
agree, the lifecycle page looks not good and I will work internally on that.

The "end of fix" date exists "since always" and was initially created to avoid that customers expect hotfixes for regular bugs. In the past, we delivered also security fixes after "end of fix" and if needed, that would also happen to V12 for a certain amount of time.

Would a separate "end of security fix" column with X months on top of "end of fix" help?

Best regards
Hannes

[JPMS]

Hannes,

A basic security requirement for your customers is that you don't utilise software that no longer receives security fixes. If you are considering a product's EOL, that is the key date and we need to know when that is. It is not enough to say that you may make security fixes available "for a certain amount of time" after the 'end of fix' date because we don't know that you definitely will and we don't have a firm date until when.

So yes, a published date for security fixes, would make our lives a lot easier. We then have a definite date to plan around.

That isn't to say there isn't some risk about continuing to utilise software that is no longer receiving fixes but there is also a risk moving to a new version. It is something we have to balance all the time. Ideally, there would be a longer overlap between two versions, when both are fully supported. Some companies offer that, some, like yourselves, don't.

[FCU_JE]

I asked this question quite a while ago. No answers. No updates to the policy.

veeam-backup-replication-f2/veeam-produ ... 00014.html

[HansMeiser]

Hello,

thanks to all posters.
I think we were able to clarify our perspective as backup administrators to the software manufacturer.
We dont need fixes for programmfunctions after date x, but we need a clear stance and assurance regarding security updates. Typical this end with final end of support.
"may or may not...", "mostly" does not meet my expectations.

Thanks,
Hans

[HannesK]

Hello,

JPMS & HansMeiser: it's clear what is needed, thank you.
FCU_JE: thanks for that thread, I will add that to the conversation that I started earlier today.

Best regards
Hannes

[RubinCompServ]

End of Fix for v12, September 2025, Release Date v13, November 2026! You're on your own for the gap between?!

Not sure where you see a release date of anything of November 2026 (especially considering that v13 was released months ago already), but it seems obvious that it was a typo.

[JPMS]

The typo was mine!

My post should have read November 2025 (not 2026). The point is that there is a one/two month gap between stopping support for v12 and v13 being released, which clearly doesn’t make sense.

[RubinCompServ]

Not that it makes it any better, but v13 (13.00) was released in September as the appliance. November was when the Windows version was released. Maybe someone "oopsied" when updating the table (or - and this is my guess - Veeam pushed off the Windows launch to November from the original September date and they forgot to update the EoS for v12).

[iDeNt_5]

I think the same, also because it was not possible to upgrade from v12 to v13 appliance...

[StephKT]

Hello,
agree, the lifecycle page looks not good and I will work internally on that.

The "end of fix" date exists "since always" and was initially created to avoid that customers expect hotfixes for regular bugs. In the past, we delivered also security fixes after "end of fix" and if needed, that would also happen to V12 for a certain amount of time.

Would a separate "end of security fix" column with X months on top of "end of fix" help?

Best regards
Hannes

Yes, a separate "end of security patch" column is needed.
It is also necessary to clarify the situation, as it is based on numerous assumptions. Therefore, the definition of "End of fix" needs to be updated.

[HannesK]

Hello,
I just wanted to let you know, that https://www.veeam.com/product-lifecycle.html got updated with the requested information. You might have also noticed, that we released a security patch for V12 some weeks ago.

Best regards
Hannes

[kevin.boddy]

Hi Hannes,

Why is the end of fix and end of support for v13 that same date? That makes no sense.
Surely those should be at least 1 year apart.

Thanks
Kevin

[HannesK]

Hello,
it's a good question, but nothing I was working on to solve this forum thread. My goal was to have a clear documentation and not changing the content except for the November 2025 gap that was mentioned above.

About your question: that is something that will be adjusted once timelines are clearer. There will be a support overlap between major versions also in future.

Best regards
Hannes

[ObiWan]

Chiming in this discussion I must say I'm a bit concerned how Veeam (Product Management and higher ups) seems to treat their own products.
If this

Updating to the latest supported version is always our recommendation.

and

I appreciate your points and am sorry to hear you had challenges on v13

is the current technical stand for the product management, then I'd really like to know the CV of those people. Because I would rather say that a mature software version should NOT, ever, be EOL'd by the introduction of a fresh new version. Especially your software.
Your software is a backbone of IT infrastructure. And reading forum threads about various topics regarding v13 and older versions, I may conclude that there are Non-Technicians who make decisions for a very critical part of IT infrastructure.
In my case we are a small enterprise who can't afford a whole test system for testing v13 before upgrading. Reading about all these problems with the new version 13 is not surprising. But what really surprises is the nonchalant way to communicate to actually use a complete new version in production as a RECOMMENDATION. We simple can't upgrade to a version with these bugs and flaws. Hell, we just got the information, that your latest MS365 Backup solution didn't actually backuped the content from SharePoint files...https://www.veeam.com/kb4835

Every serious senior technician KNOWS that software matures, no major software version from any vendor until this day was without any bugs and flaws. For a critical software like yours this mindset is dangerous and is really unsettling.

I really hope for the future of Veeam that this mindset changes ASAP. If the product management wannts to know how to rupture the reputation of their software the fastest way, keep going.

Best regards

[petesteven]

Hi Kevin,

the end of fix and end of support is probably still the same date, since there isn't a newer version yet.
In the past, “next GA” was listed under “End of fix.” You can see that here as well.

https://web.archive.org/web/20250327214 ... cycle.html

[m.novelli]

Chiming in this discussion I must say I'm a bit concerned how Veeam (Product Management and higher ups) seems to treat their own products.
If this



and



is the current technical stand for the product management, then I'd really like to know the CV of those people. Because I would rather say that a mature software version should NOT, ever, be EOL'd by the introduction of a fresh new version. Especially your software.
Your software is a backbone of IT infrastructure. And reading forum threads about various topics regarding v13 and older versions, I may conclude that there are Non-Technicians who make decisions for a very critical part of IT infrastructure.
In my case we are a small enterprise who can't afford a whole test system for testing v13 before upgrading. Reading about all these problems with the new version 13 is not surprising. But what really surprises is the nonchalant way to communicate to actually use a complete new version in production as a RECOMMENDATION. We simple can't upgrade to a version with these bugs and flaws. Hell, we just got the information, that your latest MS365 Backup solution didn't actually backuped the content from SharePoint files...https://www.veeam.com/kb4835

Every serious senior technician KNOWS that software matures, no major software version from any vendor until this day was without any bugs and flaws. For a critical software like yours this mindset is dangerous and is really unsettling.

I really hope for the future of Veeam that this mindset changes ASAP. If the product management wannts to know how to rupture the reputation of their software the fastest way, keep going.

Best regards

So True

Marco

[stevepogue]

Last November, I started receiving these warning messages about my Windows 11 25H2 clients.
"Microsoft Windows 11 (Next, 64-bit, Technical Preview) Backup agent installation is not required
Microsoft Windows version installed on this machine is not officially supported by Veeam yet"
I opened a support ticket with Veeam and was advised that the latest version of the V12 windows agent was just released and it was not aware of the 25H2 version. I was advised that I would have to update to V13 to get these warning msgs to stop.
Last November, the whole world knew that 25H2 was about to be released. Why doesn't Veeam work with Microsoft to identify the OS version numbers and build it in the product?

[eldxmgw]

Veeam really need to get a grip on this sort of stuff. They seem to have lost all interest in what their customers need and what modern IT standards require.

There is already a significant discussion on the massive bloatware that Veeam is becoming here post541369.html. I only mention this because it is another example of how Veeam has lost touch with what IT professionals need.

Backup software is one of the critical parts of IT infrastructure. It is not something you rush to change when a vendor brings out a major new version with lots of changes. Does Veeam not understand that? Are your own internal IT practices so poor that you leap on every bit of shiny new stuff that's dangled in front of you as soon as it comes out?

You even make yourself look foolish - https://www.veeam.com/product-lifecycle.html. End of Fix for v12, September 2025, Release Date v13, November 2026! You're on your own for the gap between?!

I get that you want to move people on ASAP but it is rarely that simple for us. I can just about live with a 'no fixes' policy but it is essential that there is a guarantee of security fixes for a reasonable period of time. I would suggest six months, so upgrades can be properly planned, tested and implemented.

Well, that's how it is.

What also surprises me about Veeam is that more product managers than technicians are speaking up here. And the fact that the wording regarding nuanced thinking among Veeam staff is completely in line with the official guidelines is quite striking, but also not unexpected.
However, the framing by the Veeam product managers, if you really get to the heart of the matter, is completely indoctrinated, devoid of any independent opinion, and entirely in line with mainstream guidelines to distract from the core problem.

VBR 13 is, in my opinion, still a beta version of an inflated and truly unnecessary so-called major release, just to jump on some fancy feature bandwagon of the industry instead of consolidating and maintaining version 12.
This major release hopping is strongly reminiscent of the late 2000s and early 2010s, when Apple began releasing OSX major releases in exactly the same way, on or even less frequently. And that continues to this day. Anyone can see what's become of it.

VBR 12 is being increasingly abandoned instead of being maintained. References to VBR 13 are constantly being made. Since at least autumn/winter 2025, there have been numerous sources publicly criticizing the resource-deficient VBR 13.
And that's not even mentioning the constant bugs, which are particularly problematic with this type of infrastructure-critical software.
One has to wonder why Veeam was so eager to announce VBR 13 with such fanfare, only to release it in such a state, gradually abandon VBR 12, and apparently prefer to develop the final version of such critical software with customer feedback through R&D forums.

The handling of the situation is analogous to VSA.
Announced with great fanfare, and in my opinion, released as an unfinished product—with a good concept, but fundamentally lacking features.
Here too, as with VBR 13, for example, it's clear that development towards maturity is driven primarily by feedback via R&D forums.
Again, the customer is obviously the cheapest beta tester, labeled "final." And then there are Veeam employees, especially at VSA, who seriously try to tell you that tape implementation isn't planned because it would require an ID0, and that this isn't supported by the security appliance, and should therefore be seen more as a feature.
On the other hand, these same people promote MFA requirements -> encryption and/or QR code -> mobile phone -> camera -> ... // ... -> spot the flaw!
I don't know what kind of poor management training they attended, but their conflict resolution skills and technical arguments (which aren't really arguments) look quite different.
There are also quite a few sources and platform economies that have been shaking their heads at this unfinished product for months.
Regarding this, I can only recommend the following thread, among others: tape-f29/tape-linked-to-hardened-reposi ... 01631.html

I would strongly advise against replacing VBR 12 with VBR 13. Regarding the potential patch flaw, I would simply optimize a physical VBR 12 host as much as possible towards an airgap and freeze it, and/or keep the underlying, e.g., a Windows Server 2025, up-to-date using something like a batch patch in offline and cached mode via another instance.
Provided the VBR 12 host is isolated, has no WAN access, and is otherwise clearly encapsulated within the LAN, missing security patches for VBR 12 might not matter much even in dozen of years.
Moreover, for a tape ecosystem it is generally better to use the established VBR major release, rather than switching to a buggy or an absolutely overloaded new major release where, to stick with the tape topic, feature reductions have been introduced.

[m.novelli]

I'm sticking to v12 for the vast majority of customer. I'm installing v13 only on brand-new VBR Servers

Marco