Well, I did some more digging. The parser itself is fine. What matters is the hashing order of the symbols. There's one particular sequence that drives the factorization routine off the rails.

#include <ginac/ginac.h>
#include <iostream>
#include <algorithm>

int main()
{
    GiNaC::symbol ar[5];
    std::sort(std::begin(ar), std::end(ar), [](const auto &a, const auto &b)
              { return a.gethash() < b.gethash(); });
    GiNaC::symbol &A = ar[4], &w = ar[0], &K = ar[1], &C = ar[2], &B = ar[3];
    A.set_name("A");
    B.set_name("B");
    C.set_name("C");
    K.set_name("K");
    w.set_name("w");
    std::cout << factor(w*w*w*B*B*A-2*w*w*w*K*K*B*B*A+w*C*C*A+w*w*w*K*K*K*K*B*B*A) << '\n';
}

Interestingly, for the library version before 1.8.0, there were four more permutations that produced weird output:

// GiNaC::symbol &A = ar[0], &w = ar[1], &K = ar[2], &C = ar[3], &B = ar[4];
// GiNaC::symbol &A = ar[1], &w = ar[0], &K = ar[2], &C = ar[3], &B = ar[4];
// GiNaC::symbol &A = ar[2], &w = ar[0], &K = ar[1], &C = ar[3], &B = ar[4];
// GiNaC::symbol &A = ar[3], &w = ar[0], &K = ar[1], &C = ar[2], &B = ar[4];

As Richard B. Kreckel <kreckel at in.terlu.de> wrote, this is not a bug. So, I apologize for misreporting.
But still, the result of factorization looks somewhat counterintuitive.

With best regards,
Ivan

On Wed, Feb 2, 2022 at 12:52 AM Vladimir V. Kisil <V.Kisil@leeds.ac.uk> wrote:
        Hello,

        It seems that the problem is not with the factor method but with the
  parser. Take the following modification of your example:

#include <ginac/ginac.h>
#include <iostream>
#include <sstream>

int main()
{
    std::string input("w^3*B^2*A-2*w^3*K^2*B^2*A+w*C^2*A+w^3*K^4*B^2*A");
    while (true)
    {
        std::ostringstream s;
        GiNaC::parser reader;
        GiNaC::ex e = reader(input);

        s << factor(e);
        if (s.str().length() <= input.length())
            continue;
        std::cout << s.str() << '\n';
        return 0;
    }
}

  It behaves as your example and quickly terminates with a strange
  output. However, if the declaration "GiNaC::parser reader;" will be
  moved out of the loop then the programme will cycle forever.

  Best wishes,
  Vladimir
--
Vladimir V. Kisil                 http://www.maths.leeds.ac.uk/~kisilv/
  Book:      Geometry of Mobius Maps       https://doi.org/10.1142/p835
  Soft:      Geometry of cycles         http://moebinv.sourceforge.net/
  Jupyter notebooks:        https://github.com/vvkisil?tab=repositories
>>>>> On Mon, 31 Jan 2022 00:01:48 +0300, Ivan Vasilyev <grabesstimme@gmail.com> said:

    IV> Hi! I believe there's an intermittent bug in GiNaC::factor()
    IV> function.  Sometimes it leaves uncancelled terms with seemingly
    IV> random coefficients like:

    IV> w*(w^2*(K^4*B^2+B^2-2*K^2*B^2)+196*w^2*K^4+196*w^2+C^2-196*w^2*(1+K^4-2*K^2)-392*w^2*K^2)*A

    IV> The minimal code to reproduce the bug in GiNaC 1.8.2 is:

    IV> #include <ginac/ginac.h> #include <iostream>

    IV> int main() { std::string
    IV> input("w^3*B^2*A-2*w^3*K^2*B^2*A+w*C^2*A+w^3*K^4*B^2*A"); while
    IV> (true) { std::ostringstream s; GiNaC::parser reader; s <<
    IV> factor(reader(input)); if (s.str().length() <= input.length())
    IV> continue; std::cout << s.str() << '\n'; return 0; } }

    IV> Also, this problem can be reproduced on
    IV> https://daninet.github.io/ginac-wasm/ with the same expression
    IV> being calculated several times in a row:

    IV> factor(w^3*B^2*A-2*w^3*K^2*B^2*A+w*C^2*A+w^3*K^4*B^2*A);

    IV> With best regards, Ivan.