I want to bring attention to a deeply concerning practice that Epicor has recently demonstrated regarding a 0-day Browser UX exploit in Kinetic. Instead of treating this as the urgent security vulnerability it is, Epicor required the end user to post it as an “Idea” on their public Ideas portal: KIN-I-6273: https://epicor.ideas.aha.io/ideas/KIN-I-6273
Why This Is a Problem
1. Security Is Not a Feature Request
Security vulnerabilities—especially 0-day exploits—are not “nice-to-have” features or workflow improvements. They are critical flaws that put customer data, business processes, and compliance at risk. Treating a 0-day as an “Idea” trivializes the risk and delays the response.
2. Public Disclosure Risks
By forcing users to post details (even vague ones) on a public forum, Epicor increases the risk of malicious actors discovering and exploiting the vulnerability before a fix is available. This is the opposite of responsible disclosure and puts every customer at greater risk.
3. Shifting Responsibility to Customers
Epicor’s approach essentially says: “If you find a security hole, go post it as a suggestion and hope it gets enough votes.” This is not just bad practice—it’s a fundamental misunderstanding of vendor responsibility in enterprise software. Security issues should be triaged, acknowledged, and patched by the vendor, not left to languish in a backlog of feature requests.
4. Undermining Trust
When a vendor treats critical security issues as community suggestions, it erodes customer trust. We rely on Epicor to take security seriously and act swiftly—not to crowdsource urgency or visibility.
What Should Happen Instead
Immediate escalation: Security vulnerabilities should be handled through a dedicated, confidential channel—not a public “Ideas” board.
Prompt hotfixes and backports: All supported versions should receive patches as soon as possible.
Clear communication: Epicor should notify customers of risks and mitigations, not bury them in a voting system.
Final Thoughts
Epicor, this is a wake-up call. Security is not optional, and it’s not a popularity contest. Forcing users to post 0-day exploits as “Ideas” is not just bad optics—it’s bad security. Please do better.
If you agree, upvote the linked Idea and let Epicor know that security deserves immediate, professional attention—not a spot in the suggestion box.
I completely agree with your sentiment, Chris. The idea of funneling critical issues into the “Ideas” portal is fundamentally flawed. Issues like security and financial accuracy are not feature requests—they’re baseline requirements for any ERP system. Treating them as optional enhancements undermines the principles of responsible software development and risk management.
This example is especially concerning due to its clear violations of security best practices. When an ERP system treats security as a feature request, it not only misrepresents the severity of the issue but also delays the decisive action that should be taken immediately. More importantly, it erodes trust in the development company and its commitment to safeguarding customer data and operations.
Ideas is a blanket solution to have us post things to fix or implement. As many complaints as we have about the Ideas portal, not too long ago we didn’t have an ideas portal. And we complained about not having a place to post “Ideas”.
It’s just a process to collect the topics and process them, previously it was support cases and that need to be separated.
Back in October 2023, Rich Riley had me reach out to Nick Dyer (Application Security Manager at Epicor) about setting up some kind of responsible disclosure process, but I never got a reply from him. There should be a secure way to do this. Epicor Ideas and EpicCare are too open, IMHO.
I agree that EpicCare and PRBs are potentially too insecure as well; they are at least a little better than Epicor Ideas.
I’d honestly love a direct bug/security reporting tool. Especially considering how vague PRBs can be, and how difficult it can be to find potentially related issues when interfacing with EpicCare.
I can also understand the headache of needing a dedicated team to review user submissions privately, categorize, organize, and merge related reports.
Submitting bugs/security issues to “Epicor Ideas,” however, is an abject failure IMO. Treating “Epicor Ideas” as a blanket solution is ineffective and problematic at best.
No we didn’t. Support submitted them to development and if they got rejected support wrote up an enhancement request and we were able to search and read all of it in the SCR database.
Oh, and we did have a place to post ideas - here. The old category is still there.
The root of this entire problem is Epicor’s obsession with the “working as designed” nonsense. They have taught their developers that if they can prove the original dev request said that it should be that way, then that shall FOREVER be unquestioned. This flawed thinking is what has lead development to reject hoards of legitimate bugs. Ideas was just a band aid to try to quiet the dissatisfaction about this state of affairs. But now that has failed too since we can’t even post ideas without being censored. I am sure this post itself will be censored in short order.
This is not the first time I have heard of reported security vulnerabilities going un-responded to when non public channels are used (for obvious reasons)…
I don’t think it’s a sweep it under the rug thing. I think many VC owned companies are under pressure to innovate vs. cleaning up code or improving security. For companies like LastPass and Ivanti, lack of attention to the old code has not been helping their investment.
To be clear. I wasn’t reporting any issues. I was hoping to see a responsible disclosure program created instead of issues leaking into public places.
That was my Idea. I recommend leaving it memory holed outside of explicit disclosure channels. We won’t know for a while if that’s a step towards fixing the problem or fixing the messenger.
Hopefully, this is a step in the right direction. Whether users should consider other options likely depends significantly on each customer’s unique situation.
I agree, it should have been handled through a more confidential disclosure channel as well. Hopefully, this is a fix-the-problem thing, not a fix-the-symptoms one.
I’d like to know if you still have access, since it sounds like you were the original author.
KIN-I-6273: https://epicor.ideas.aha.io/ideas/KIN-I-6273
