Should Comodo users stop using Comodo?

Status
Not open for further replies.
@bazang and @Divergent,

I am afraid that @Digmor Crusher is right. This thread has some rules caused by the logic explained in the OP.
Most of what you both posted either contradicts the rules of this thread or is untrue.
You probably cannot accept that the proof method in this thread forces us to initially believe in the statements of the Comodo staff about the new version of CIS, if there is no solid evidence that the Comodo staff is wrong.

I can understand this because you believe, based on Comodo's history (you have the right to do it), that Comodo and CIS 2025 are similarly invalid as in the past.
However, in this thread, we try to prove it (if possible) and not just believe in it.

For example, let's analyze the statement below used by @bazang.
STATEMENT: "Any arguments that Comodo is fixing bugs is mere speculation because nobody has visibility into that process - not even the Comodo forum moderators."

However, Comodo staff announced that 40 older bugs are no longer present in the new version. This contradicts the STATEMENT, except when one assumes that Comodo lies (Comodo is bad). So, the STATEMENT is untrue or contradicts the rules of this thread.
Furthermore, there is no evidence that most of the older bugs were not fixed (no such reports). The lack of visibility into the process of fixing bugs does not prove that all the bugs are unfixed. I confirmed two issues that were silently fixed in the new CIS version. I have the full right to insist that the STATEMENT is untrue.

I will not analyze your other statements; you can do it by yourself.
Unfortunately, your last posts do not bring anything interesting to this thread. Of course, the same posts can be valuable in other threads about Comodo, which can use another logic of proof.
If you cannot accept the rules of this thread, please stop posting here. If you have something interesting to say, please post without breaking the rules.
I’ve already shared multiple posts in this thread presenting evidence of unresolved vulnerabilities. Rather than addressing the evidence directly, you’ve deflected and suggested that my posts are somehow off-topic or against your rules. Instead of avoiding the issue, please explain why these vulnerabilities cannot be fixed promptly, as other vendors manage to do. Why should users be expected to grant Comodo the highest level of trust, allowing it to run with deep system privileges, without proper accountability?
 
I’ve already shared multiple posts in this thread presenting evidence of unresolved vulnerabilities. Rather than addressing the evidence directly, you’ve deflected and suggested that my posts are somehow off-topic or against your rules. Instead of avoiding the issue, please explain why these vulnerabilities cannot be fixed promptly, as other vendors manage to do. Why should users be expected to grant Comodo the highest level of trust, allowing it to run with deep system privileges, without proper accountability?

It is easy.
The Comodo staff announced that those vulnerabilities are not a direct threat to Comodo (do not require immediate patching). We are forced in this thread to believe them until those vulnerabilities are not exploited in the wild. It is not important if you, @bazang, or another person believes that Comodo is wrong.
 
Last edited:
It is easy.
The Comodo staff announced that those vulnerabilities are not a direct threat to Comodo (do not require immediate patching). We are forced in this thread to believe them until those vulnerabilities are not exploited in the wild. It is not important if you, @bazang, or another person believes that Comodo is wrong.
You're correct that Comodo's position is that the vulnerabilities "do not require immediate patching," but that position is the core of the problem. The argument that "we are forced... to believe them until those vulnerabilities are exploited in the wild" is a dangerous reversal of security best practices.

This is a Reactive, Not a Proactive, Security Model.

The foundation of modern cybersecurity is to be proactive, to patch known, severe vulnerabilities before they can be used in an attack. Waiting for a vulnerability to be actively exploited is a reactive stance. It essentially means accepting that some users will become victims before the vendor decides to act.

Vendor Risk vs. User Risk

A vendor's assessment of a threat is based on their own business priorities. It does not and cannot account for the risk to an individual user's personal data. What Comodo deems an acceptable risk for their business is not necessarily an acceptable risk for our home computers. The public CVSS score of 8.8 (HIGH) for CVE-2025-7097 and CVE-2025-7098 from the National Vulnerability Database shows that the broader security community considers these flaws to be severe.

Trust Must Be Earned, Especially with High Privileges

My original question was about trust and accountability, and this situation is a perfect example. We grant antivirus software the highest level of privilege on our systems. In return, we should expect the highest level of accountability. A vendor's silence and failure to patch publicly disclosed, high-severity vulnerabilities in a timely manner breaks that trust.

The issue isn't about whether we "believe that Comodo is wrong." The issue is that there is verifiable, public evidence of critical security flaws. Choosing to ignore that evidence based on a vendor's unverified statement is not a sound security practice.
 
  • Like
Reactions: simmerskool
You're correct that Comodo's position is that the vulnerabilities "do not require immediate patching," but that position is the core of the problem. The argument that "we are forced... to believe them until those vulnerabilities are exploited in the wild" is a dangerous reversal of security best practices.

It does not matter. You did not prove that the Comodo vendor is not right in the case of the new Comodo.
There is no evidence that Comodo was exploited more than the top AVs, while not following your standards.

The issue isn't about whether we "believe that Comodo is wrong." The issue is that there is verifiable, public evidence of critical security flaws. Choosing to ignore that evidence based on a vendor's unverified statement is not a sound security practice.

You can believe in this, and it can be true for other AVs.
But there is no evidence that Comodo users suffer because of Comodo's lower standards.
You would lose a court case against Comodo.
 
Last edited:
It does not matter. You did not prove that the Comodo vendor is not right in the case of the new Comodo.
There is no evidence that Comodo was exploited more than the top AVs, while not following your standards.



You can believe in this, and it can be true for other AVs.
But there is no evidence that Comodo users suffer because of Comodo's lower standards.
You would lose a court case against Comodo.
The "Argument Invalidation" Tactic

The opening, "It does not matter," is a powerful rhetorical move. It doesn't refute my point, it declares my entire premise irrelevant. This immediately shuts down the line of reasoning I've presented and is a clear signal that you do not intend to engage with the substance of my argument.

For the person on the receiving end, this feels deeply dismissive.

The "Burden of Proof" Loop

Your repeated claims of "I did not prove..." and "There is no evidence..." create a frustrating loop. Even though I had just provided examples, this tactic allows you to ignore them completely and reset the debate.

Impact on Me

This forces me to constantly defend the existence of my evidence rather than discuss its meaning. It's a defensive position that makes it impossible to advance the conversation. It feels like baiting because it's a tactic to exhaust me, not to understand me.

The Appeal to an Unseen Standard

You state I didn't prove Comodo was wrong "while not following your standards." You then counter that Comodo isn't suffering because of their "lower standards."

Impact on Me

You frame my position as an arbitrary, personal "standard" while implicitly treating the "real world" outcome (Comodo not suffering) as the only standard that matters. This minimizes my argument as a matter of opinion rather than one based on security best practices, as I originally stated.

The Conclusive, Adversarial Framing

The final sentence, "i would lose a court case against Comodo," is the masterstroke of this style. It accomplishes three things that feel like baiting.

It casts YOU as the judge. You are no longer a fellow debater but the authority rendering a final verdict.

It reframes the debate as a battle. A discussion about security practices becomes a zero-sum legal fight, which is inherently adversarial.

It's an unfalsifiable claim. You can't prove or disprove this hypothetical, so it serves only as a way for you to declare victory without winning the actual argument.

Synthesis

I Felt Like I was Baited


I felt like I was being baited because the communication I received was not structured to facilitate a good-faith debate. Instead, it used a series of rhetorical tactics designed to dismiss, invalidate, and exhaust my position without ever substantively engaging with the evidence I provided.

Regardless of whether your "intent" was to genuinely bait me or you simply have an incredibly blunt and arrogant communication style, the impact on me was the same. The techniques you used are textbook examples of how to make an interlocutor feel unheard and engaged in a pointless, bad-faith exercise.
 
I want to step in here before this thread goes further off course. A few recent posts have shifted away from technical discussion of Comodo and into arguments about tone, motives, or debating style. That kind of meta-discussion quickly derails the thread and adds to frustration.


To keep this thread useful for everyone, please:


  • Stay focused on technical points, evidence, and verifiable information.
  • Avoid commenting on how others argue or framing their posts as “baiting.”
  • If the discussion starts to feel unproductive or frustrating, it’s fine to step away and come back later.

We all know Comodo threads can heat up fast - let’s do our best to keep this one constructive and on-topic.
 
Wow. There is a lot of drama I've missed in just a week lol.
I am not sure what leads to this “chewing” of Comodo. After forum administrator had to get involved (first time I see that), as one of the more influential users here, I will attempt to conclude the discussion with several facts:

-Comodo containment is not broken. Comodo will efficiently sandbox questionable executables and scripts, there are still threats like DLL sideloading that will be poorly handled. These require efficient behavioural blocking that will analyse the dll & exe relationships. All reputation-based systems suffer from trusted code abuse.

-During our analysis, we didn’t notice any fatal bugs. However, it is important to note that our analysis is short and shallow, on one machine. It can not be compared to feedback of multitude of users, some of which have changed already a few machines and have followed Comodo closely. Also, not everyone will configure Comodo the way we have configured it.

-There is no evidence of bug fixes, whatever the forum moderators have gathered as a list, merely states this will be sent to the developers. This is a generic, template-based response (from the sort of “thank you for your feedback, we will forward it to the relevant teams” and this feedback 9/10 times results in nothing being done).
Panda was also forwarding to the developers information about BSODs 10 years ago, and it still causes such to this date.
There is no proper issue tracking/ticket based system and no change-log that proves the issues were resolved. This list cannot serve as a changelog.

The same list also contains suggestions such as firmware scanner, keystroke encryption and others which are nowhere to be found. This confirms that it does not enumerate what’s already done. The fact that 2 different lists contain different number of bugs is also not an evidence, it is an assumption.

-There is no evidence that Comodo vulnerabilities have been exploited. However, cyber security best practices involve taking preventive measures before the threat has become a problem. You take an umbrella before it starts raining outside and not 3 days after the rain has already stopped.
Comodo’s dismissive attitude and 0 support create a feeling of an “antivirus from Temu”, one that is poorly developed, even if risks are theoretical and minimal.
Some users could be perfectly fine with that, others obviously won’t be. There is no right or wrong, it’s a matter of personal taste.
 
Last edited:
You did not prove that the Comodo vendor is not right in the case of the new Comodo.
I have professional colleagues at Comodo. I know how things work internally there, whether you or anyone else believes me. What others believe, I just don't care. I stand by what I have already stated. You are entitled to believe whatever you wish. If you want to believe one thing or other using logic based only upon what you can see publicly on the Comodo forum and the posts made there (which many are not by Comodo staff - and none of them made by Comodo employees are "official".

I know the product owner, Melih, and only statements made by him or his executive staff does he consider "official Comodo statements.")

I am not being argumentative. I am merely making statements of fact.

There is no evidence that Comodo was exploited more than the top AVs, while not following your standards.
I never said that it was, because I know that it is not exploited more than even AVs not in the "top tier."

But there is no evidence that Comodo users suffer because of Comodo's lower standards.
I am not observing anyone other than Decopi who argues that "Comodo users suffer."

I know that I don't believe or think any Comodo user "suffers" except when they experience some issue, bug, or who knows what when they're messing with Comodo and they cannot use it, they get infected because they don't know how it works, or they have to clean install the OS to just be rid of it all and move on with their lives or be a glutton for punishment and try Comodo again.

You would lose a court case against Comodo.
Nobody will win a case against Comodo because of the language in the EULA ("Offered 'AS IS' and use at your own risk"), Terms of Service, and other corporate legal protections, and the way that the current global legal system virtually always favors or sides with the software publisher.

It is easy.
The Comodo staff announced that those vulnerabilities are not a direct threat to Comodo (do not require immediate patching). We are forced in this thread to believe them until those vulnerabilities are not exploited in the wild. It is not important if you, @bazang, or another person believes that Comodo is wrong.
It's not easy. "Comodo staff" do not speak officially on behalf of either the software owner, Melih, or other senior Comodo executives. That - and I know it to be true 100% - is based upon Melih's rules. I've been inside Comodo's facilities multiple times and I know how it works within that company. Only Melih or his designated executives are permitted to make "official Comodo statements." Comodo staff are only minions and anything they state is not "official."

You are mistaken to interpret what is posted on the Comodo forum literally and as the definitive source of fact and truth - because that reading and interpretation is not correct. The "truth" or "facts of the matter" - meaning Comodo reality - are much more nuanced than a literal read and Spock logic.

  • If the discussion starts to feel unproductive or frustrating, it’s fine to step away and come back later.

We all know Comodo threads can heat up fast - let’s do our best to keep this one constructive and on-topic.
Time for me to visit a Romanian beach before winter ruins it all for me, and think of better times. There's still time to sit on the beach there and soak in the mid-day sun.

Leaving Comodo behind to those that want to waste their valuable time. No offense intended whatsoever or a "low jab" taken with the language I just used. People waste time watching the tele all the time. Nobody finds that offensive. I see no difference when there are those that want to debate and beat the Comodo dead horse - which has been beaten so much - that not even the bones remain. It's just all dust.

I have no skin in this game. I don't even use Comodo. I shed that hot mess eons ago. My choice. Others should do as the see fit.

PS - I meet Romanians in Turkiye all the time, especially in Istanbul.
 
Last edited:
  • Hundred Points
Reactions: dmknght
Comodo users should continue using it. Comodo users preferring default settings or applying minimal changes with HIPS off should have a positive experience; most bugs are usability-related. Users who want to harden Comodo, create custom HIPS rules, or use HIPS would encounter issues affecting protection and convenience. People wanting an effective antivirus, Valkyrie real-time, regular bug fixes, and active development should stop using Comodo. Comodo will only bring disappointment if you set expectations.

I prefer and will continue to use Comodo as long as they keep it compatible with Windows releases. As noted above, I adjust Comodo slightly and disable HIPS, and this approach has worked flawlessly for me for years. The simple use, default settings, minimal changes, and HIPS off are also perhaps reasons for Comodo users who enjoy and prefer it.
 
You and some others use extreme arguments that can be easily disproved. For example, when you say that all bugs are unfixed. I know one bug and one vulnerability that were recently (silently) fixed. This significantly decreases the strength of your argumentation.
I did mention except the few ones labeled as FIXED on the List Of Bugs by Comodo Staff at a later point in this discussion, didn't I?
If you state that fixing one, two or three bugs decreases the strength of my arguments significantly while knowing that CIS has over 100 bugs that's fine with me, still over 100 bugs unfixed......
 
The "Argument Invalidation" Tactic

The opening, "It does not matter," is a powerful rhetorical move. It doesn't refute my point, it declares my entire premise irrelevant. This immediately shuts down the line of reasoning I've presented and is a clear signal that you do not intend to engage with the substance of my argument.

Yes, but only in this thread. We do not want to show beliefs here or show arguments that our beliefs have a solid background. There were several threads on MT with such logic, and you could present your beliefs and arguments for those beliefs there. You can also open another thread.

Here is a joke about vulnerable behavior.

@Divergend (a prosecutor): This man leads a very unhealthy life. He drinks too much, eats too much fat, and smokes like a fiend. He has a very good chance of dying before he's 60 unless the courts force him to adopt immediately a healthy lifestyle.

@Andy Ful (defense attorney): Objection. This man celebrates his 100th birthday today.

As I said, please post here without breaking the rules. Open your own thread if you do not accept the rules. It is so simple.
 
-There is no evidence of bug fixes, whatever the forum moderators have gathered as a list, merely states this will be sent to the developers.

Things are more complicated because there were a few lists with many bugs and proposed improvements reported by users over a period of a few years. Those lists were published officially on Comodo's forum.
At least two bugs/vulnerabilities were silently fixed, and I confirmed this. However, those fixes were not announced officially.
The list of 40 older bugs that were tested in the new version and did not appear in those tests was published by Comodo staff in August January 2024. The staff member posted that the rest of the bugs that were confirmed to happen were pushed to the development team.

So there is official evidence of some bug fixes and some evidence that bugs can be silently fixed by Comodo.
There is no solid evidence that the rest of the bugs were fixed (no official statement). However, there is also no evidence that most of those bugs were not fixed (the bug reports for the new version contain only a few bugs).

We all agree that Comodo's bug maintenance is different from being clear and does not fulfill the high standards expected by Enterprises.:)(y)

Edit.
Corrected the wrong date of publishing the list.
 
Last edited:
The list of 40 older bugs that were tested in the new version and did not appear in those tests was published by Comodo staff in August 2024. The staff member posted that the rest of the bugs that were confirmed to happen were pushed to the development team.
This is no prove that those older 40 bugs have been fixed.
Where is this test? Where is the statement of Comodo Staff or Change Logs which tell us that those 40 bugs have been fixed?
 
  • Like
Reactions: Jack
Could you please provide evidence of that, I may have missed that.

Tested and unconfirmed bugs in CIS 12.3.1.8104 beta (January 2024, in the previous post, I put the wrong date):


Tested and confirmed bugs (August 2024):

1759056755718.png


Assuming that you were right that there were more than 100 older confirmed bugs, both lists confirm that many old bugs were fixed or unconfirmed for the new CIS version.
 
Last edited:
Yes, but only in this thread. We do not want to show beliefs here or show arguments that our beliefs have a solid background. There were several threads on MT with such logic, and you could present your beliefs and arguments for those beliefs there. You can also open another thread.

Here is a joke about vulnerable behavior.

@Divergend (a prosecutor): This man leads a very unhealthy life. He drinks too much, eats too much fat, and smokes like a fiend. He has a very good chance of dying before he's 60 unless the courts force him to adopt immediately a healthy lifestyle.

@Andy Ful (defense attorney): Objection. This man celebrates his 100th birthday today.

As I said, please post here without breaking the rules. Open your own thread if you do not accept the rules. It is so simple.
Your response is noted. You do not refute my analysis of the "Argument Invalidation" tactic, rather, you confirm its deliberate implementation within the specific operational parameters of this thread. Your justification is that this forum section is not for substantiating beliefs with logic or evidence.

Let us dissect the analogy you presented as a jest.

Prosecutor (Divergent)

Presents a logical, evidence-based, probabilistic argument. The subject's lifestyle variables (diet, smoking, alcohol consumption) lead to a high-probability

conclusion: P(death before 60)≫P(survival to 100). This is a sound, data-driven forecast.

Defense Attorney (Andy Ful)

Presents a single, outlying data point ("This man celebrates his 100th birthday today").

Your analogy is flawed in two critical ways

It mistakes an outlier for a refutation of probability.
The man reaching 100 does not invalidate the prosecutor's assessment that his lifestyle made such an outcome highly improbable. It simply means a low-probability event occurred.

My reasoning, like the prosecutor's, is based on a logical framework, which you are attempting to dismiss by pointing to a single, overriding "rule" that exists outside of that framework.

It commits a category error. Your analogy equates a verifiable, objective fact (a man's age) with a subjective, constructed forum rule. One is a statement about reality; the other is a procedural guideline for a specific, artificial environment.

You have correctly identified the function of your interjection. It is the "Objection" that halts the logical process.

You have confirmed that the rule in this thread is to operate on assertions without providing their "solid background." This creates an intellectual sandbox where premises are accepted axiomatically and are intentionally shielded from the scrutiny required for valid argumentation.

My point was never about breaking the rules. It was about identifying and analyzing them. You have clarified the rule is to intentionally disengage from the substance of an argument. Understood
.

My analysis of the tactic stands, and you have now provided the explicit context for its use. My inquiry is not about playing the game, it is about understanding the game's flawed design.
 
Prosecutor (Divergent)

Presents a logical, evidence-based, probabilistic argument. The subject's lifestyle variables (diet, smoking, alcohol consumption) lead to a high-probability

conclusion: P(death before 60)≫P(survival to 100). This is a sound, data-driven forecast.

It was an anecdotal example that generally true reasons may not apply to a particular case. Your standards can be generally true, but you did not prove that they must apply to Comodo. (y)
High standards related to vulnerabilities can be generally important for top AVs, but Comodo has no obligation to apply them. There is no evidence in the wild that Comodo's customers are less safe in practice with Comodo's current standards. Comodo can go to court against you and probably win the case, as you try to discourage Comodo customers without tangible evidence. You use probabilities that have no visible confirmation for the Comodo case.
 
It was an anecdotal example that generally true reasons may not apply to a particular case. Your standards can be generally true, but you did not prove that they must apply to Comodo. (y)
High standards related to vulnerabilities can be generally important for top AVs, but Comodo has no obligation to apply them. There is no evidence in the wild that Comodo's customers are less safe in practice with Comodo's current standards. Comodo can go to court against you and probably win the case, as you try to discourage Comodo customers without tangible evidence. You use probabilities that have no visible confirmation for the Comodo case.
Your argument has pivoted from defending a procedural rule to questioning the applicability of standardized security principles. Each point will be addressed sequentially.

On Anecdotes vs. General Principles

You reclassify your flawed analogy as an "anecdotal example." This is a correct classification. However, an anecdote, by definition, is a logically insufficient tool for invalidating a general principle, particularly in the domain of risk assessment. Security engineering is predicated on general principles precisely because individual outcomes are unpredictable. A single data point (an anecdote) does not disprove a probabilistic model, it is merely one coordinate within the distribution.

On Applicability and Obligation

You state Comodo has "no obligation to apply" high standards. This introduces a logical fallacy by conflating technical evaluation with legal or contractual obligation. My analysis is not concerned with Comodo's corporate obligations. It is an assessment of their security posture against established best practices. Whether a manufacturer is *obligated* to install seatbelts is a legal question, whether a car is *safer* with seatbelts is a technical one. You are attempting to invalidate a technical assessment by raising an irrelevant legal tangent.

On "No Evidence in the Wild"

This is a classic argument from ignorance (`argumentum ad ignorantiam`). The absence of publicly available evidence of exploitation is not evidence of security. A core function of security analysis is to identify and mitigate latent risks *before* they are exploited. The probability of an exploit given a vulnerability, $P(\text{Exploit} | \text{Vulnerability})$, is never zero. To wait for "visible confirmation" via customer incidents is a reactive, not a proactive, security model. It is fundamentally unsound.

On Legal Threats

Your introduction of a hypothetical lawsuit ("Comodo can go to court against you") is an appeal to force (`argumentum ad baculum`). This is a rhetorical tactic used to silence critique by introducing an unrelated threat. It has no bearing on the technical merits of the discussion and is therefore discarded as irrelevant data. I'm going to analyze logical and technical claims, not engage in speculative legal scenarios.

You claim I use "probabilities that have no visible confirmation." This statement reveals a foundational misunderstanding of risk. The entire discipline of security is built upon such probabilities. We do not need to observe a building burning down to confirm that storing flammable materials next to a furnace is a high-risk configuration. The risk exists independently of its manifestation. Your line of reasoning advocates for ignoring the fire code until a fire has occurred.
 
Last edited:
Status
Not open for further replies.